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ABSTRACT 


The  Department  of  the  Navy  (DoN)  maintains  an  inventory  of  Small  Tactical  Unmanned 
Aircraft  Systems  (STUAS).  These  systems  are  designed  for  payload  modularity  to 
support  user  selection  of  multiple  mission  configurations  in  order  to  meet  any  unique 
mission  need.  Numerous  mission  ready  payloads  have  been  developed  for  each  system, 
and  only  need  to  be  integrated  in  order  to  become  part  of  the  fielded  unmanned  aerial 
system  (UAS)  configuration.  Unfortunately,  the  DoN  does  not  have  a  method  that 
maintains  sufficient  systems  engineering  (SE)  discipline  to  rapidly  integrate  and  field 
new  mission  configurations  to  the  fleet  in  support  of  aggressive  schedules  and  urgent  user 
needs.  The  typical  fielding  time  frame  can  range  from  24  to  36  months,  instead  of  the 
desired  6  to  18  months.  Furthermore,  without  a  sufficient  SE  approach,  risk  to  mission 
success  is  not  well  understood.  This  paper  captures  all  applicable  requirements  for 
fielding  a  new  capability  onto  an  existing  UAS,  and  using  an  SE  approach,  outlines  a 
process  to  rapidly  integrate  payloads  DoN  system.  The  process  identified  provides  a 
comprehensive  list  of  integration  requirements;  a  cost,  schedule,  and  performance  trade¬ 
off  analysis;  technical  risk  associated  with  each  tradeoff  option;  and  recommendations  on 
how  to  best  support  a  rapid  fielding  timeline. 
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EXECUTIVE  SUMMARY 


The  Department  of  the  Navy  (DoN)  does  not  have  a  method  that  maintains  sufficient 
systems  engineering  (SE)  discipline  to  rapidly  integrate  and  field  new  mission 
configurations  into  its  fleet  of  Small  Tactical  Unmanned  Aerial  Systems  (STUAS)  in 
support  of  aggressive  schedules  and  urgent  user  needs.  Furthermore,  without  a  sufficient 
SE  approach,  risk  to  mission  success  is  not  well  understood.  The  DoN  Small  Tactical 
Unmanned  Aerial  Systems  (STUAS)  are  designed  for  payload  modularity  to  support 
user-selection  of  multiple  mission  configurations  in  order  to  meet  any  unique  mission 
needs.  Numerous  mission  ready  payloads  have  been  developed  for  each  system,  and  only 
need  to  be  integrated  in  order  to  become  part  of  the  fielded  UAS  configuration.  The 
typical  fielding  time  frame  of  a  new  payload  can  range  from  24  to  36  months,  instead  of 
the  desired  6  to  18  months. 

This  paper  captures  all  applicable  requirements  for  fielding  a  new  capability  onto 
an  existing  UAS,  and  using  a  SE  approach,  outlines  a  process  to  rapidly  integrate 
payloads.  An  outcome  of  this  report  was  the  creation  of  a  new  Rapid  Transition  Process 
(RTP)  that  can  be  used  in  the  transition  of  any  new  technology.  NAVAIR  has  a  lot  of 
separate  procedures  which  apply  to  the  fielding  and  transition  of  technologies  to  the  fleet 
or  warfighter,  but  a  process  to  bring  all  of  the  procedures  together  in  an  orderly  and 
efficient  manner  does  not  exist.  To  determine  the  best  implementation  of  this  process  a 
detailed  SE  analysis  was  conducted  of  the  current  payload  integration  process.  This 
analysis  resulted  in  a  stream  lined  integration  process,  identified  in  Figure  that  provides 
stakeholders  the  ability  to  trade  cost  schedule  and  performance,  while  managing  risk,  in 
order  to  meet  mission  objectives. 
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Figure  1 :  RAIN  Project  Rapid  Transition  Process  Streamlined  Integration 


The  process  provides  a  comprehensive  list  of  system  level  integration 
requirements,  a  cost,  schedule,  and  performance  trade  off  analysis,  risk  assessments 
associated  with  each  tradeoff  option,  and  a  recommendation  on  to  how  best  support  a 
rapid  fielding  timeline.  The  options  are  to  pursue  full  certifications,  pursue  certification 
subjected  to  a  low  risk  timeline  reduction  (LRTR)  strategy,  and  pursue  certifications 
subject  to  an  intermediate  risk  timeline  reduction  (IRTR)  strategy.  The  LRTR  strategy 
involves  using  previously  certified  subsystems  in  the  payload  to  bypass  certifications  that 
drive  the  schedule,  CAT  3  flight  certification,  and  joint  DT  and  OT.  The  IRTR  strategy 
involves  the  use  of  interim  certifications  for  the  ones  among  the  schedule  drivers  that 
allow  them,  a  CAT  3  flight  certification,  and  shifting  OT  to  initial  fielding.  During  the 
tradeoff  analysis  three  potential  payloads  where  reviewed,  a  LASER  Designator  payload, 
a  Passive  Electronic  Warfare  payload,  and  an  Active  Electronic  Warfare  payload.  The 
requirements  for  each  payload  were  identified,  and  can  be  seen  in  Figure  1.  The  tradeoff 

analysis  identified  three  options  to  execute  payload  integration,  complex  payload 
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integration,  simple  payload  integration,  and  highly  mature  payload  integration.  Under 
each  option  three  scenarios  where  modeled,  to  include  full  certification  (BL),  low  risk 
timeline  reduction  (LRTR),  and  intermediate  risk  timeline  reduction  (IRTR),  details  are 
shown  in  Figure  3.  Based  on  these  options  and  scenarios,  a  range  of  rapid  integration 
possibilities  has  been  identified.  Each  possibility  provides  an  assessment  of  risk 
acceptance,  allowing  tailoring  of  a  detailed  SE  process  to  fit  cost  and  schedule 
constraints,  while  maintaining  sufficient  SE 

The  RTP  was  designed  to  streamline  the  current  disjointed  integration  approach 
employed  by  the  PMA  in  fielding  a  new  payload  combination  on  a  modular  STUAS 
through  early  identification  of  the  complete  set  of  required  certifications.  It  will  also 
support  a  rapid  fielding  decision  by  providing  the  steps  needed  to  pursue  full  or  interim 
certifications.  This  was  done  by  performing  the  RTP  functions  show  in  Figure  2  with  the 
assistance  of  physical  components  in  the  form  of  checklists;  certification  requirements 
listings  by  system  type;  timeline  reduction  options  listings,  descriptions,  and  ratings; 
simulation  results  for  cost  and  schedule  for  following  certification  baseline  or  timeline 
reduction  strategies  and  was  comprised  of  the  seven  (7)  steps  that  follow 
Figure  2. 


Figure  2:  Rapid  Transition  Process  Functional  Flow 


Step  1 :  Initiation  of  the  RTP  by  the  PMA 
Step  2:  Determine  Certifications  to  Pursue 
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Step  3:  Collect  Certification  Data:  Perform  iteratively  with  analyzing  the  certification 
data. 

Step  4:  Analyze  Certification  Data:  Perform  iteratively  with  collecting  the  certification 
data. 

Step  5:  Address  Risk 

Step  6:  Develop  Certification  Package  for  Decision  Maker 
RTP  Conclusion 

The  RTP  ends  when  fielding  decision  package  is  judged  to  be  complete  by  the 
decision  maker,  and  a  fielding  decision  is  made. 
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Figure  3:  STUAS  Payload  Requirements 

(Red=Certification  Required,  Green/Blue=Certification  Not  Required) 


xxv 


The  results  of  the  trade  study  produced  a  number  of  possible  options  for  payload 
integration.  Each  options  risk  was  identified,  allowing  stakeholders  to  make  an  educated 
decision,  as  to  whether  a  specific  option  can  meet  timelines,  while  maintaining  sufficient 
SE  rigor  to  ensure  risks  are  understood  and  mitigated.  The  summary  of  the  results  can  be 
seen  in  Figure  4,  Figure  5,  Figure  6  and  Figure  7  based  on  risk  tolerance  levels  if  this 
processes  was  utilized  a  payload  integration  can  be  conducted  to  meet  a  range  of  users 
needs  with  a  sound  cost,  schedule,  and  performance  balance. 


H?!nvp!f|  I  [complex)  3  [mature  1  fclnufrfe)  Hramplex|i  ^mature)  1  [Umpief  2^omp*e»)  3  jrnature) 

Las.cr  Deflator  Fative  £w  Active- EM 

■  Schedule  \WU* )  BL  ■  Schedule  (Whs)  IRTR  uU  hedule  \  Wka)  LRFR 


Figure  4:  Schedule  Summary  Results 
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Figure  5:  Cost  Summary  Results 


Figure  6:  Schedule  Risk  Rating  Summary  Results 
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Figure  7 :  Added  Performance  Risk  Rating  Summary  Results 
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I.  INTRODUCTION  AND  BACKGROUND 

A.  INTRODUCTION 

1.  Problem  Background 

The  Department  of  the  Navy  (DoN)  maintains  a  relatively  small  inventory  of 
Small  Tactical  Unmanned  Aerial  Systems  (STUAS).  These  systems  are  designed  to  be 
highly  modular  and  support  multiple  configurations,  allowing  for  user  selection  of 
payloads  based  on  unique  mission  needs.  This  modularity  reduces  the  necessity  for 
multiple  unique  Unmanned  Aerial  Systems  (UAS)  platforms  and  their  associated  life 
cycle  costs,  while  still  providing  mission  flexibility.  Technology  developers  are 
successful  in  designing  new  payloads  which  integrate  into  the  UAS  platform  and  meet 
mission  requirements.  This  provides  a  payload  technology  that  is  at  a  suitable 
Technology  Readiness  Level  (TRL);  meets  all  technical  requirements  of  the  applicable 
UAS  Interface  Control  Document(s)  (ICD);  and  size,  weight,  and  power  (SWAP) 
requirements.  Typically,  while  the  requirements  with  regard  to  the  specific  payload- 
vehicle  interface  are  met,  the  payload  developers  do  not  address  the  DoN  System-level 
requirements  for  integration  and  fielding. 

It  is  the  responsibility  of  the  system’s  integrator  to  ensure  that  the  platform,  with 
its  new  payload,  meets  all  regulatory  and  statutory  requirements  for  deployment  to  the 
fleet.  This  is  done  by  obtaining  the  necessary  technical  certifications  (e.g.,  laser,  Li 
battery,  airworthiness  approvals,  for  instance)  imposed  by  regulatory  requirements  on  the 
systems.  An  example  of  a  statutory  requirement  placed  on  UAYs  that  must  be  addressed 
for  successful  integration  is  H.R1815  National  Defense  Authorization  Act  for  Fiscal  Year 
2006  (HR  Bill  2005),  which  states  all  data  links  used  by  a  UAV  must  use  the 
government-developed  Tactical  Common  Data  Link  (TCDL).  This  particular  example 
has  caused  challenges  in  the  past  because  some  payloads  are  developed  with  their  own 
Command  and  Control  (C2)  data  links  so  they  do  not  have  to  integrate  with  the  existing 
UAS  data  links,  reducing  the  complexity  of  payload  level  integration.  Unfortunately,  not 
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meeting  the  TCDL  requirement  requires  re-engineering  of  the  payload  to  complete 
systems-level  integration,  causing  delays  in  fielding. 

2.  UAS  History 

The  early  history  of  Unmanned  Aerial  Systems  (UAS)  began  with  Perley’s  aerial 
bomber  in  1863  and  Eddy’s  surveillance  kite  in  1898.  During  the  American  Civil  War  the 
inventor  Charles  Perley  obtained  a  patent  for  his  design  of  a  hot  air  balloon  known  as  the 
unmanned  aerial  bomber  which  could  carry  a  heavy  load  of  explosives  with  a  timer. 
Because  weather  conditions  and  air  currents  made  it  hard  to  estimate  the  time  to  set  the 
fuse  his  design  proved  to  be  inaccurate  and  unreliable.  By  1898  the  first  military  aerial 
surveillance  photos  were  taken  during  the  Spanish-American  War  using  a  kite  with  a  long 
string  attached  to  the  shutter  release  of  the  camera. 

Although  those  two  (2)  early  inventions,  using  primitive  Unmanned  Aerial 
Vehicle  (UAV)  technology,  achieved  very  limited  success,  they  had  attracted  attention 
because  of  their  promise  for  wartime  applications  in  covering  areas  considered  to  be  too 
dangerous  and  inaccessible  to  be  overflown  by  manned  reconnaissance  aircraft.  Growing 
from  original  concepts,  flying  bombs  and  pilotless  drone  aircraft  such  as  the  Kettering 
Aerial  Torpedo 

Figure  1)  built  in  the  1910s  during  World  War  I  became  the  precursors  to  modern- 
day  cruise  missiles.  Most  of  them  were  jet-propelled  and  low-  flying,  mostly  gliding  to 
the  intended  target.  In  some  cases  they  were  guided  to  its  target  by  a  simple  on-board 
computer.  The  development  of  such  weaponry  brought  UAV  technology  to  the  next  level 
of  sophistication  (Hughes  1993). 
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Figure  1 :  Kettering  Aerial  Torpedo  in  the  1910s  (18  NOVA  2013) 

By  World  War  II,  numerous  unmanned  craft  were  built  around  the  world. 
However,  it  was  not  until  the  1930s  that  the  U.S.  Navy  started  its  initial  experiments  with 
unmanned  aerial  aircraft  controlled  by  radio  signals.  One  outcome  of  these  endeavors 
was  the  Curtiss  N2C-2  biplane  drone,  which  flew  for  the  first  time  without  a  pilot  in  late 
1937.  During  the  last  days  of  the  Second  World  War,  Germany’s  invention  of  the  V-l 
flying  bomb  (also  known  as  buzz  bomb  or  doodlebug)  made  new  progress  in  UAV 
history  by  demonstrating  its  significant  potential  during  combat.  This  pilotless 
monoplane  carrying  a  2000-pound  warhead  was  a  pulse-jet-powered  predecessor  of  the 
modem  cruise  missiles  and  rockets  launched  from  the  ground  (ground-to-air  missiles).  It 
was  not  radio-controlled,  but  pre-programmed  to  fly  150  miles  before  dropping  its  bomb, 
causing  catastrophic  damage  (18  NOVA  2013).  The  development  of  such  a  deadly 
weapon  convinced  the  U.S.  military  to  lay  more  extensive  groundwork  on  post-war  UAV 
programs  (Bone  and  Bolkcom  2003). 

During  the  Vietnam  and  Korean  wars,  UAVs  gained  more  credibility  and  made 
further  inroads  into  American  and  allied  military  programs.  The  American  armed  forces 
became  more  involved  in  maturing  their  own  technology  and  influenced  their  allies  to  do 
so  as  well.  Investing  time,  knowledge,  and  money  in  high-technology  weapons  became  a 
trend  in  the  international  community  (11  Wikipedia  2013).  By  the  late  1950s,  military 
aircraft  were  already  capable  of  travelling  at  speeds  of  Mach  2.  Building  upon  the  success 


3 


of  UAVs  as  targets,  the  U.S.  military  started  to  take  increasing  advantage  of  UAS 
potential  to  achieve  other  previously  unachievable  and  hazardous  missions.  This 
expansion  brought  about  the  development  of  the  UAYs  with  the  capability  to  accomplish 
missions  through  remote  control. 

In  1960  the  U.S.  Air  Force  launched  its  first  stealth-technology  aircraft  and  began 
modifying  the  war- fighting  UAVs  to  achieve  a  new  mission:  reconnaissance.  The  earlier 
jet-propelled,  subsonic  target  drone  BQM-34A  (formerly  designated  Q-2C  Firebee)  was 
turned  into  the  AQM-34L  reconnaissance  drone  for  long-range  reconnaissance, 
undercover  surveillance,  and  leaflet-dropping  missions  in  Vietnam  and  other  parts  of 
Southeast  Asia.  One  of  the  most  critical  surveillance  missions  of  Firebee  was  radar 
detection  of  surface-to-air  missiles  over  China  and  North  Vietnam  (18  NOVA  2013). 
Because  of  its  accomplishment,  Firebee  received  further  attention  and  recognition  for 
national  security  in  the  armed  forces.  Military  strategists  discovered  the  UAV’s  flexibility 
and  started  searching  for  ways  to  maximize  its  potential.  Ultimately,  the  Firebee  was 
reformed  to  deliver  payloads,  conducting  its  very  first  flight  test  on  December  20th,  2002 
as  an  armed  UAV  (Bone  and  Bolkcom  2003). 

In  1965,  the  single  high-speed  and  ultra-stealth  D-21  UAV  developed  for 
photographic  aerial  reconnaissance  by  Lockheed  with  a  maximum  range  of  3,000  miles, 
to  operate  at  a  height  of  80,000  feet  and  the  ability  to  follow  a  preprogrammed  path.  This 
Mach-4  aircraft  was  carried  on  the  back  of  a  manned  Lockheed  M-12  Blackbird  variant 
aircraft  and  considered  to  be  the  fastest  UAV  developed  to  date.  However,  the  D-21 
project  was  shelved  because  of  its  catastrophic  failures  (18  NOVA  2013)  in  all  of  the  four 
(4)  operational  missions.  The  failures  prompted  the  U.S.  military  to  develop  new  UAVs 
suited  for  intelligence  gathering  at  high  altitude  and  out  of  range  of  hostile  missiles, 
resulting  in  the  invention  of  the  Ryan  Special  Purpose  Aircraft  or  SPA  147  (18  NOVA 
2013). 

In  the  late  1970s  the  Israelis  developed  several  UAVs,  such  as  the  Scout,  which 

were  eventually  operated  in  Lebanon  in  1982.  With  its  low  radar  signature  and  small  size, 

the  Scout  was  almost  impossible  to  shoot  down.  This  new  successful  UAV  technology 

impressed  U.S.  observers,  causing  them  to  establish  a  joint  development  of  UAVs  and 
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marked  the  beginning  of  the  evolution  of  experimental  projects  into  actual  acquisition 
programs  (Bone  and  Bolkcom  2003).  A  rocket-boosted  UAV  that  took  off  from  runways 
on  land  or  carrier  flight  decks  known  as  Pioneer  (Figure  2)  was  one  of  the  resultant  joint 
developments.  To  this  day  Pioneer  is  still  being  utilized  to  confirm  high  priority  mobile 
targets  using  the  Synthetic  Aperture  Radar  (SAR)  from  other  aircraft  (18  NOVA  2013). 


Figure  2:  Pioneer  and  its  parts  (From  Pioneer  UAV  2002) 

After  recognizing  the  significance  of  UAVs,  several  countries,  with  the  U.S.  in 
the  forefront,  ushered  in  a  proliferation  of  UAV  innovations  in  the  1990s,  including  many 
impressive  capabilities  that  were  far  more  advanced  than  their  precursors.  This  led  to  the 
development  of  the  General  Atomics  MQ-1  Predator  (Figure  3),  a  medium-altitude,  long- 
endurance  UAV,  is  probably  one  of  the  most  sophisticated  in  the  U.S.  military  arsenal. 
The  Predators  were  innovative  as  they  were  able  to  be  configured  to  complete  multiple 
missions  from  a  single  platform.  By  carrying  cameras,  sensors,  and  munitions,  the 
primary  capabilities  of  Predator  are  conducting  armed  reconnaissance  and  fulfilling 
forward  observation  roles  such  as  surveillance  and  target  acquisition  (13  U.S.  Air  Force). 
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Over  the  last  100  years,  manned  canvas-over- wood  biplane  aircraft  have  turned 
into  entirely  autonomous  advanced  aerial  systems  with  the  capabilities  of  achieving  all 
types  of  battlefield  roles,  including  but  not  limited  to:  cargo  transportation,  at-sea  or  in¬ 
flight  replenishment,  surveillance,  data  and  photo  collection,  and  target  acquisition  and 
engagement.  Instead  of  using  manned  aircraft,  those  missions  are  now  mostly 
accomplished  around  the  world  through  both  fixed-wing,  and  more  recently,  rotary-wing 
aircraft  UAVs.  The  size  and  capabilities  of  the  systems  range  from  large  vehicles  that  can 
carry  offensive  weapons  to  a  miniature  system  used  for  surveillance  that  can  be  carried  in 
a  backpack.  With  existing  technology,  a  UAV  can  be  operated  as  a  stand-alone  unit  or  as 
part  of  a  system  of  systems  known  as  a  UAS.  For  instance,  the  RQ-7  Shadow  UAS  is 
comprised  of  four  (4)  unmanned  aerial  (UAS),  two  (2)  Ground  Control  Stations  (GCSs), 
a  portable  GCS,  a  Launcher,  two  Ground  Data  Terminals  (GDTs),  a  portable  GDT,  a 
Remote  Video  Terminal,  and  other  related  equipment.  In  addition,  military  units  are  also 
fielded  with  a  maintenance  support  vehicle. 

Anxious  to  take  advantage  of  incredible  potential  of  such  weapons  systems, 
countries  around  the  world  are  continually  pouring  in  resources,  money,  and 
technological  investments  into  UAS-related  programs.  Currently,  the  five  (5)  most 
common  UAVs  of  the  United  States  Department  of  Defense  are:  Predator  and  Global 

Hawk  of  the  Air  Force;  Pioneer  of  the  Navy  and  Marine  Corps;  and  Hunter  and  Shadow 
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of  the  Army  (Bone  and  Bolkcom  2003).  The  countries  known  to  possess  UAVs  are 
China,  France,  Germany,  Greece,  India,  Israel,  Iran,  Italy,  Japan,  Jordan,  Pakistan,  South 
Africa,  Russia,  Switzerland,  Turkey,  United  Kingdom,  and  the  United  States  (Multiple 
and  Wikipedia).  Only  recently  have  UASs  expanded  their  critical  nature  in  combat 
missions,  not  only  because  of  technological  sophistication  but  also  due  to  perceived 
military  requirements  to  fulfill  national  objectives.  International  crises  are  believed  to  be 
the  driving  forces  for  enhancement  of  war-fighting  capabilities.  In  the  future  it  is 
anticipated  that  UASs  will  play  a  crucial  role  in  the  world’s  conflicts. 

B.  CURRENT  INTEGRATION  PROCESS  FOR  MODULAR  PAYLOADS 


Figure  4:  Current  Operational  View  (Before  the  RTP  process) 


The  transition  process  between  integration  of  the  payload  into  the  target  platform 

and  its  ultimate  integration  into  the  encompassing  DoN  System  is  not  well-defined.  Each 

DoN  System  level  requirement  is  handled  independently  by  a  different  organization 

within  the  government  where  the  knowledge  of  that  particular  process  and  its  associated 

requirements  is  typically  self-contained.  To  date,  little  effort  has  been  made  to  take  a 
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system  level  approach  to  bridge  those  lines  of  communication  between  organizations  (as 
shown  in  Figure  4)  and  collect  all  the  information  regarding  certifications  and  regulations 
into  one  readily  accessible  repository  and  create  a  defined  system  of  processes. 

The  lack  of  a  system-level  approach  to  integration  elongates  the  timeline  because 
certifications  captured  later  in  the  process  no  longer  have  the  ability  to  be  pursued  in 
parallel  with,  and  may  delay  others.  For  example,  during  the  review  of  an  Airworthiness 
Certification  request,  the  Electrical  Power  subject  matter  expert  (SME)  may  require  a 
Battery  Certification.  If  this  is  not  pursued  in  conjunction  during  the  data  collection 
effort,  the  Airworthiness  Certification  will  be  delayed  until  the  Battery  Certification  is 
obtained.  Technical  challenges  arise  when  interim  approvals  or  waivers  for  these 
emergent  certifications  are  obtained  to  satisfy  the  rigid  fielding  schedule  without  fully 
understanding  the  consequences  of  those  decisions.  For  example,  a  full  Battery 
Certification  may  take  six  (6)  weeks  to  obtain.  An  interim  approval  may  be  obtained 
within  a  matter  of  weeks  but  may  deploy  a  thermal  battery  with  unknown  operating 
restrictions  and  potentially  dangerous  consequences  (e.g.,  explosive  hazard). 

With  the  current  undefined  process,  once  a  payload  is  delivered,  it  takes  between 
24  and  36  months,  depending  on  complexity  of  the  effort,  to  thoroughly  satisfy  all  the 
applicable  statutory  and  regulatory  requirements  before  the  system  can  be  integrated  into 
the  DoN  inventory.  This  timeframe  is  unacceptable  in  supporting  the  rapidly  evolving 
environment  to  which  our  war-fighters  are  exposed.  For  the  sake  of  expediency  the 
integration  timeline  is  often  shortened  by  waiving  or  inadvertently  overlooking  the 
systems-level  requirements  without  an  understanding  of  technical  risk  generated  by  these 
decisions,  This  often  results  in  a  rapidly-fielded  system  which  may  be  technically 
insufficient  to  meet  mission  needs  and  could  pose  substantial  risks  to  the  warfighters  in 
the  future.  To  address  these  technical  challenges  and  reduce  the  integration  timeline, 
systems  engineers  must  provide  leadership  with  the  information  to  balance  cost, 
schedule,  and  performance  risk  to  the  program  when  obtaining  interim  approvals  or 
waivers. 
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c. 


PROBLEM  STATEMENT 


The  DoN  does  not  have  a  documented  process  that  maintains  sufficient  Systems 
Engineering  (SE)  discipline  to  rapidly  integrate  and  field  new  mission  configurations  for 
their  inventory  of  modular  STUAS  to  the  fleet  to  support  aggressive  schedules  and  urgent 
user  needs  in  a  timeframe  of  6  to  18  months  instead  of  the  typical  24  to  36  months  while 
minimizing  technical  risk  to  mission  success.  The  requirements  for  whether  or  not  to 
perform  each  certification  (sub  process)  in  the  current  process  are  not  well  understood 
and  are  often  addressed  in  a  reactive  fashion,  sometimes  when  identified  as  the  entry 
criteria  for  a  different  certification  or  approval 

1.  Objectives 

The  objective  of  this  project  was  to  create  and  document  a  comprehensive  process 
for  the  integration  of  new  capabilities  of  modular  UAS  into  the  DoN  System,  then 
conduct  a  SE  trade  study,  similar  to  an  Analysis  of  Alternatives  (AoA),  to  address  the 
UAS  systems  integration  challenges  outlined  above.  The  trade  study’s  goal  was  to  find 
the  best  way  to  rapidly  integrate  new  configurations,  meet  technical  requirements, 
balance  technical  risk,  and  produce  options  for  a  rigorous  SE  process  that  can  be  tailored 
to  meet  program  needs. 

2.  Project  Intention 

The  purpose  of  this  project  was  to  conduct  a  trade  study  of  a  comprehensive  SE 
plan  to  address  payload  integration  of  DoN  System  requirements  onto  Program  Manager 
Air  (PMA)-263  STUAS  platforms.  To  complete  this  study,  a  documented  process  of  the 
procedures  to  facilitate  integration  and  fielding  of  new  capabilities  was  developed.  The 
documented  process  was  used  for  modeling  and  simulation  (M  and  S)  of  integration  into 
the  DoN  System.  The  trade  study  allowed  a  tailoring  of  DoN  System-level  requirements 
to  support  the  rapid  integration  and  fielding  of  UAS  capabilities. 

In  the  trade  study,  three  (3)  different  integration  situations  were  applied  to  the 

payload  types  to  which  the  project  was  constrained: 
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•  Simple  -  The  payload  operates  almost  independently  and  requires  minimal 
integration  with  the  host  platform.  It  cannot  leverage  off  the  existing 
certifications,  but  must  pursue  separate  ones  for  its  own  sub-components. 

•  Complex  -  The  payload  must  be  fully  integrated  with  the  host  platform,  utilizing 
existing  sub-components  that  already  have  the  required  certifications  (e.g.  Laser, 
battery).  Only  the  payload  sub-components  will  need  to  pursue  certification. 

•  Mature  -  The  payload  has  been  integrated  and  certified  for  operation  on  a 
different  platform.  The  remaining  certifications  to  be  pursued  are  those  required 
for  a  new  configuration  of  an  existing  platform  (e.g.  Airworthiness, 
Interoperability). 

In  addition  to  pursuing  full  certifications,  two  strategies  were  implemented  during 
each  of  these  integration  situations  to  reduce  the  overall  certification  timeline: 

•  Full  Certification  -  All  applicable  certifications  are  pursued  for  full  approval. 

•  Intermediate  risk  timeline  reduction  (IRTR)  -  Interim  approvals  were  pursued 
for  the  applicable  certifications  that  have  long  durations. 

•  Low  risk  timeline  reduction  (LRTR)  -  The  payload  was  composed  of  sub¬ 
components  that  have  existing  certifications  (e.g.  Spectrum,  CDL). 

3.  Research  Questions 

The  following  questions  were  identified  by  the  RAIN  Project  Team  as  topics  that 
the  ultimate  user  of  the  developed  process  should  understand  prior  to  its  implementation: 

•  Which  requirements  are  applicable  to  each  specific  type  of  payload? 

•  What  are  the  dependencies  between  certifications?  Which  certifications  must  be 
done  sequentially?  Which  can  be  done  in  parallel  (i.e.,  are  some  prerequisites  for 
others)? 

•  What  was  a  typical  timeline  (or  range)  for  each  certification? 

•  Can  a  method  be  identified  to  integrate  and  field  a  new  capability  within  18 
months? 
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•  Which  requirements,  applicable  to  the  payload,  can  be  waived  or  granted  interim 
approval? 

•  Where  applicable,  what  does  a  waiver  or  interim  approval  authorize  for  each 
certification? 

•  Which  trade-offs  (full  certification,  interim  approvals,  or  use  of  previously- 
certified  components)  can  be  done  to  support  a  compressed  timeline? 

•  Can  the  compressed  timeline  be  achieved  without  the  pursuit  of  waivers? 

•  Can  the  compressed  timeline  be  achieved  without  the  pursuit  of  interim 
approvals? 

•  For  each  certification  that  drives  the  schedule  with  available  timeline  reduction 
options,  what  are  the  risks  if  an  interim  approval  was  obtained? 

D.  PROBLEM  SCOPE 


Figure  5:  RAIN  Project  Problem  Scope 


The  scope  of  this  project,  shown  in  Figure  5,  was  limited  to  new  capabilities  that 
can  be  integrated  into  modular  STUAS  in  the  existing  PMA  263  inventory.  The  candidate 
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payloads  were  limited  to  those  that  meet  the  technical  requirements  of  the  platform’s  ICD 
and  would  not  require  re-design  of  the  UAS  or  modification  of  the  current  airframe. 


1.  Assumptions 

The  following  assumptions  were  applied  as  the  entrance  criteria  to  the  RAIN 

project: 


•  Capability  satisfies  technical  requirements  of  platform  (ICD  and  SWAP)  for 
which  it  was  developed 

•  Capability  satisfies  TRL  requirements  for  which  the  technology  developer  was 
applying 

•  Capability  has  sufficient  logistical  support  (spares  and  repairs)  from  developer 

•  Capability  has  stable  configuration  that  requires  no  further  changes,  except  those 
identified  as  needed  by  integration  process 

•  Capability  does  not  require  modification  of  airframe  for  successful  platform 
integration 

•  Existing  certifications  for  the  platform  automatically  applies  to  the  payload  that 
fits  within  the  system  (i.e.,  Air-Ship  Integration  and  Transportability) 

2.  Constraints 

The  following  constraints  were  applied  to  the  RAIN  project: 

•  Statutory  and  Regulatory  requirements  for  UASs  must  be  addressed 

•  Timeline  must  support  fielding  within  18  months 

•  Some  requirements  cannot  be  waived  or  granted  interim  approval 

•  Detailed  certification  analysis 

•  Timeline  reductions  were  aggregated  into  two  (2)  types  of  strategies  for  the 
purposes  of  conducting  simulation  and  analysis. 

•  The  effects  of  reducing  the  time  to  address  a  single  certification  by  itself  was 

not  investigated  or  subjected  to  simulation. 
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•  Payload  types  typically  integrated  onto  PMA  263  platforms: 

•  Laser  designator 

•  Electronic  Warfare  (EW)  signal  collection  (Passive) 

•  Active  EW 

•  Communications  /  Data  Relay 

•  RADAR  Imaging 

E.  STAKEHOLDERS 


The  project  stakeholders  are  identified  in  the  list  below  and  shown  in  Figure  6. 
Project  stakeholders  interface  with  each  other  and  the  RAIN  Team  to  help  guide  and 
scope  the  project,  subject  to  RAIN  advisors’  concurrence.  The  stakeholders  can  be 
broken  down  in  to  three  (3)  main  groups,  as  listed  below,  and  are  further  decomposed  in 
Figure  7.  While  main  stakeholders  exist,  when  categorized  into  three  (3)  groups,  each 
group’s  interests  were  the  same.  The  RAIN  Team’s  primary  interest  was  in  completing  a 
Capstone  project  that  showed  the  students’  mastery  of  SE  while  producing  a  useful 
product  to  other  stakeholders.  PMA-263’s  primary  interest  was  to  implement  a  rapid 
system  integration  process  while  maintaining  SE  rigor.  The  external  stakeholders’ 
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primary  interest  was  in  rapidly  fielding  new  technology  while  reducing  risk  to  technical 
challenges. 

•  RAIN  Team 

•  Students 

•  Advisors 

•  PMA263: 

•  Chief  Engineer 

•  Weapon  Systems  Integration  Integrated  Product  Team  (IPT)  Lead 
•  Configuration  Manager 

•  External  Stakeholders: 

•  APEO  (U  and  W)  Engineering 

•  Warfighters 

•  Requirements  Officers 

•  Technology  developer 


Platform 
IPT  Lead 


Requirement 

Officers 


Users  I 
Watfiphtj 


Product 


^Platform 

integrators 


Developer 


Figure  7:  RAIN  External  Stakeholders 
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External  stakeholders,  identified  in  the  list  below,  all  hold  interest  in  the  results 
of  this  project’s  trade  study  analysis.  Stakeholder  interactions  with  the  RAIN  Team  and 
each  other  are  conceptualized  in  a  cloud  formation  in  Figure  7.  PMA-263  was  interested 
in  the  risks  generated  by  different  implementation  options  of  the  SE  process  to  complete 
capabilities  integration.  Individual  platform  IPT  leads  were  interested  in  what  options 
they  have  when  implementing  an  integration  effort,  and  how  their  decisions  would  affect 
a  systems  engineer’s  ability  to  maintain  rigor  while  executing  a  program  plan.  The 
Requirements  Officers  and  end  users’  stake  in  this  project  revolved  around  delivering  the 
end  product.  The  technology  developer’s  interest  was  the  ability  to  rapidly  integrate  and 
deliver  their  products,  while  maintaining  SE  rigor  to  reduce  risk  of  future  technical 
challenges. 

•  PMA  263 

•  Platform  IPT  Lead 

•  Requirements  Officers 

•  Platform  Integrators 

•  Technology  developers 

•  Warfighters/End  Users 
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F.  TECHNICAL  APPROACH 

1.  Systems  Engineering  Process 


Needs 

Analysis 


l 

Verification  4 
Valid  alien 

n  i - 


Publish 

Process 


Process 

VelldaHen 


Process 
Integral  ian 


detailed 
Process 
Develop  men! 


Sub- Process 
testing 


Figure  8:  RAIN  Tailored  Systems  Engineering  Process  (FHA  2013) 


The  RAIN  Team  utilized  a  tailored  “Vee”  model,  as  shown  in  Figure  8  to  outline 
the  method  used  by  the  Team  to  develop  a  rapid  transition  process  (RTP),  which  was  one 
of  the  end  products  of  the  Capstone  effort.  In  the  Definition  and  Decomposition  phase, 
the  initial  analysis  of  stakeholders’  needs  to  formulate  the  top-level  requirements  was 
conducted.  Assessment  of  these  requirements  served  as  the  foundation  of  the  preliminary 
integration  process,  which  led  to  further  analysis  in  developing  the  detailed  process.  In 
the  Integration  and  Re-composition  phase,  a  model  was  established  to  simulate  execution 
of  the  developed  process,  examine  options  that  reduce  process  implementation  time,  and 
identify  viable  alternatives  as  an  outcome. 
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2.  Requirements  Development  Process 

The  Team  performed  the  following  steps  for  the  operational  phase  to  identify  the 
requirements  necessary  to  develop  the  RTP.  This  was  further  detailed  in  the  Operational 
Requirements  Document  in  Appendix  E. 

•  Define  the  operational  concept  of  the  RTP  System. 

•  Define  the  system  boundary  by  identifying  what  will  be  created  or  changed  by  the 
RTP  System.  In  addition,  identify  what  systems  will  provide  inputs  and/or  accept 
outputs  from  the  RTP. 

•  Establish  the  objectives  the  RTP  was  intended  to  meet  and  decompose  them  into 
sub-objectives  that  can  be  allocated  to  functions  and  components. 

•  Develop,  analyze,  and  refine  the  requirements. 

•  Ensure  that  there  was  a  feasible  design  to  meet  the  requirements. 

•  Define  the  qualification  requirements  to  verify  and  validate  the  resulting  RTP. 

•  Obtain  approval  of  the  developed  requirements  from  the  stakeholders  . 
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II.  REQUIREMENTS  ANALYSIS 


A.  REQUIREMENTS  DEVELOPMENT 

Through  discussions  with  the  stakeholders,  the  Team  identified  the  following  top- 
level  requirements  that  need  to  be  satisfied  for  a  successful  payload  integration  process: 

1.  Mission  Requirement 

Develop  a  process  that  facilitates  comprehensive  integration  of  a  new  payload 
into  the  DoN  System  within  18  months. 

2.  Stakeholder/User  Requirement 

Develop  a  process  that  addresses  all  applicable  statutory  and  regulatory 
requirements  needed  to  integrate  into  the  DoN  System. 

3.  System  Requirement 

Develop  a  process  that  addresses  the  following  requirements  applicable  to  the 
payload  that  needs  to  be  integrated  into  the  DoN  System: 

•  Safety 

•  Security 

•  Interoperability 

•  Compatibility 
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B.  DESIGN  REFERENCE  MISSION 


1.  Operational  Concept 


Small  Tactical  Unmanned  Aircraft  System  (STUAS) 
Rapid  Transition  Process  (RTP)  -  OV-1  Operational 
Concept  Graphic 


DISTRIBUTION  STATEMENT  A 
Approved  For  Public  Release 


Figure  9:  RTP  High  Level  Operational  View  (After) 


The  RTP  was  intended  to  help  ensure  that  the  applicable  statutory  and  regulatory 

requirements  necessary  for  comprehensive  integration  of  new  payloads  into  the  DoN 

System  are  addressed  by  the  System  Integrator  with  SE  rigor.  When  a  technology 

developer  delivers  a  new  payload  to  the  System  Integrator,  required  certifications  are 

identified  using  the  RTP.  The  individual  certification  processes  are  then  implemented  to 

collect  the  necessary  information.  If  a  data  package  was  determined  to  be  insufficient  to 

obtain  full  certification  and  no  further  information  was  available  or  can  be  obtained 

within  the  required  schedule,  the  applicable  interim  approval  process  documented  by  the 
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RTP  will  be  utilized.  The  associated  RTP  risk  assessment  for  pursuing  an  interim 
approval  for  the  applicable  certification  will  be  provided  to  ensure  the  System  Integrator 
was  aware  of  the  potential  risks  to  the  program.  Upon  compilation  of  the  required  data 
package,  the  certification  application  for  full  or  interim  approval  was  presented  to  the 
approval  authority  for  review  and  ultimate  endorsement.  A  graphic  view  of  the 
operational  concept  is  shown  Figure  9. 

2.  Rapid  Transition  Process  (RTP) 

The  RTP  was  designed  to  streamline  the  current  disjointed  integration  approach 
employed  by  the  PMA  in  fielding  a  new  payload  combination  on  a  modular  STUAS 
through  early  identification  of  the  complete  set  of  required  certifications.  It  also  supports 
a  rapid  fielding  decision  by  providing  the  steps  needed  to  pursue  full  or  interim 
certifications.  This  was  done  by  performing  the  RTP  functions  show  in  Figure  10  with 
the  assistance  of  physical  components  in  the  form  of  checklists;  certification 
requirements  listings  by  system  type;  timeline  reduction  options  listings,  descriptions, 
and  ratings;  simulation  results  for  cost  and  schedule  for  following  certification  baseline  or 
timeline  reduction  strategies. 


Figure  10:  RTP  Functional  Flow 
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a.  Initiation 

The  PMA  initiates  the  RTP  to  support  integration  and  fielding  once  the 
following  have  occurred:  A  payload  developer  delivers  a  new  payload  to  the  PMA;  the 
developer  provides  data  results  from  the  tests  it  conducted;  the  PMA  analyzes  the  data  to 
determine  if  the  payload  meets  SWAP  requirements;  the  PMA  analyzes  the  data  to 
determine  if  it  meets  the  ICD  requirements  for  the  intended  STUAS;  the  PMA  conducts  a 
fit  check  and  operational  tests  with  satisfactory  results;  and  all  results  are  satisfactory. 

b.  Determine  Certifications  to  Pursue 

•  Compare  description  of  system  of  interest  to  the  DRM  archetypes 
studied  /  listed. 

•  Pick  baseline  required  certifications  list  of  the  archetype  that 
matches  the  system  of  interest. 

•  Use  DRM  Scenarios  certifications  listing  in  Figure  12,  Figure  13, 
Figure  14,  and  Figure  22  or  Table  1  to  determine  which 
certifications  apply  to  your  system  and  integration  type. 

•  Compare  the  projected  (baseline)  certifications  schedule  and  cost 
(Figure  and  Figure  )  against  the  program  requirements. 

•  Decide  whether  schedule  reduction  was  needed. 

•  Compare  potential  schedule  reductions  from  IRTR  and  LRTR  in 
Figure  along  with  the  associated  cost  in  Figure  and  risks  in  Figure 
32,  Figure  33,  and  Figure  34  against  the  program  requirements. 
Table  2  lists  which  certifications  are  addressed  differently  for 
IRTR  and  LRTR  and  indicates  the  modification.  Additional  detail 
on  the  risks  and  descriptions  of  the  options  that  comprise  both 
IRTR  and  LRTR  are  in  the  Timeline  Reduction  Options  in 
“Section  C  Subsection  2  Project  Intention”  of  this  paper. 

•  Decide  which  timeline  reduction  strategy  best  fits  the  program 
requirements. 
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•  Use  the  certification  checklist  from  Appendix  H  to  mark  which 
certifications  are  applicable  and  which  are  not  for  the  chosen 
strategy. 

•  Use  the  certification  process  model  flow  diagram  for  the  chosen 
strategy  (generic,  IRTR,  or  LRTR)  to  guide  through  the  next  steps 
in  Appendix  F. 

c.  Collect  Certification  Data 

Perform  iteratively  with  analyzing  the  certification  data. 

•  Follow  the  order  shown  in  the  certification  process  model  flow 
diagram  for  the  chosen  strategy. 

•  From  data  provided  by  the  developer:  Follow  certification 
authorities  POC’s  guidance  on  data  needed  from  the  developers 
data  package.  Certification  authorities  and  guidance  information 
on  each  certification  can  be  found  in  the  Component  Analysis  and 
Attribute  Investigation  section  in  Appendix  H. 

•  From  T  and  E:  Conduct  test  and  evaluation  as  directed  by  the 
certification  authorities  and  SMEs  to  collect  the  data  missing  from 
the  developers  TDP. 

d.  Analyze  Certification  Data 

Perform  iteratively  with  collecting  the  certification  data. 

•  Follow  the  same  order  as  used  for  data  collection. 

•  From  data  provided  by  the  developer:  Have  the  collected  data 
analyzed  by  the  appropriate  PMA  SMEs  and  certification 
authorities  POCs  for  completeness  to  determine  what  additional 
data  was  needed  for  the  listed  certifications.  If  the  data  wasa 
incomplete  return  to  the  collect  data  step  and  either  request  more 
data  from  the  developer  or  conduct  T  and  E. 
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•  From  T  and  E:  Analyze  the  data  from  test  and  evaluation  for 
completeness.  If  incomplete  return  to  the  collect  data  step  and 
conduct  additional  T  and  E. 

•  From  analysis:  Have  the  collected  data  analyzed  against  the 
certifications’  requirements.  Depending  on  the  certification  this 
may  need  to  be  done  the  certification  authority  or  a  qualified  third 
party. 

•  Submit  favorable  results  to  the  certification  technical  approval 
authority  for  approval. 

•  Unfavorable  results  may  require  waivers  or  design  changes  in 
order  for  the  system  to  be  acceptable  for  field  use.  Research  this 
with  the  PMA  SMEs  and  certification  approval  authority  POCs. 

•  Document  the  findings  and  proceed  to  addressing  residual  risk. 

e.  Address  Risk 

•  Have  the  analysis  findings  reviewed  for  program  risk. 

•  Where  the  findings  are  not  clear  conduct  addition  analysis  or 
discussions  with  the  certification  technical  authority’s  SMEs. 

•  Provide  the  risk  assessment  to  the  fielding  decision  maker  and  to 
the  certification  package. 

f.  Develop  Certification  Package  for  Decision  Maker 

•  Detail  the  certifications  attempted  and  the  results;  approved, 
waived,  or  not. 

•  Explanation  why  only  those  certifications  were  needed. 

•  Collect  and  attach  the  signed  approvals,  along  with  any  statements 
of  residual  risk  or  limited  operational  boundaries. 

•  Attach  the  risk  assessment. 

•  Provide  to  the  system  fielding  decision  maker  in  PMA-263. 
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g.  RTP  Conclusion 

The  RTP  ends  when  the  fielding  decision  package  was  judged  to  be 
complete  by  the  decision  maker,  and  a  fielding  decision  was  made. 

3.  Projected  Operational  Environment 

a.  Operating  Environment 

The  projected  environment  in  which  the  RTP  was  expected  to  perform 
was  one  of  finite  resources. 

•  Manpower  availability  will  be  limited  due  to  the  need  for 
personnel  to  support  multiple  PMAs  simultaneously. 

•  Government  labs  and  ranges  will  also  provide  similar  limitations 
due  to  the  inflexibility  of  their  schedules. 

•  Fixed  review  board  schedules  for  the  approval  authority  may  have 
limited  ability  to  add  extra  convening  dates  for  data  package 
presentation. 

b.  Potential  Payload 

The  payload  that  will  initiate  the  RTP  process  may  have  one  or  more  of 
the  following  attributes: 

•  Insufficient  information  to  support  prompt  and/or  full  endorsement 
by  the  approval  authority. 

•  Procured  in  response  to  an  Urgent  Need  Statement,  thus  requiring 
rapid  fielding. 

•  A  commercial-off-the-shelf  (COTS)  payload,  such  that  additional 
data  or  redesign  was  not  contractually  feasible. 

•  The  types  of  payloads  that  will  be  integrated. 
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4. 


Mission  Success  Requirements 


For  the  mission  to  be  considered  a  success,  the  RTP  must  address  all  applicable 
statutory  and  regulatory  requirements  to  support  the  fielding  decision  of  the  new  payload 
into  the  DoN  System  within  18  months.  To  accomplish  this,  the  process  must  identify  the 
necessary  certifications  and  the  information  required  to  obtain  full  authorization.  The 
RTP  must  also  identify  in  what  sequence  the  applicable  certifications  must  be  pursued  to 
support  the  system  integrator’s  18-month  schedule  requirement.  If  interim  approvals  are 
required  due  to  cost,  performance,  or  schedule  constraints,  RTP  will  provide  an 
applicable  risk  assessment  to  ensure  the  system  integrator  was  cognizant  of  the  potential 
impacts  of  not  obtaining  a  full  certification. 
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5. 


Mission  Execution 


a.  Operational  Activities 


The  operational  activities  required  to  comprehensively  field  a  new  payload 
into  the  DON  System  are  shown  in  Figure  1 1  and  described  in  the  following: 

•  Address  programmatic  activities  needed  to  field  a  new  capability 

•  Obtain  the  statutory  and  regulatory  requirements  that  must  be 
satisfied  to  field  a  new  capability  on  an  existing  platform  within 
the  PMA  inventory. 

•  Perform  the  payload  integration  process  -  RTP 

•  Perform  testing  on  the  new  capability 

•  Obtain  certification  approvals 

•  Field  the  new  capability 
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b.  Operational  Situations/Mission  Scenarios 

The  RTP  was  assessed  through  modeling  and  simulation  against  three  (3) 
potential  mission  scenarios. 

(1)  Full  Certification  for  All  Applicable  Requirements 

The  data  initially  collected  from  the  Original  Equipment 
Manufacturer  (OEM)  is  reviewed  by  the  NAVAIR  SMEs  and  deemed  to  be  sufficient  to 
support  full  certification  of  the  payload.  This  scenario  was  depicted  in  Figure  12  and 
described  below: 


•  Technology  developer  delivers  the  payload  to  PMA-263 

•  PMA-263  determines  the  applicable  certification  and 
collects  data  from  the  developer 

•  Technology  developer  provides  requested  data 

•  PMA-263  forwards  data  to  SMEs  for  review 

•  SMEs  determine  that  data  is  sufficient 

•  PMA-263  develops  a  data  package  to  support  the 
certification  application  and  forwards  to  the  Approval 
Authority 

•  Approval  Authority  certifies  the  payload 

•  PMA-263  fields  the  platform  with  the  new  payload 
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Figure  12:  Full  Certification  Use-Case 
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Requirement 


(2)  Additional  Testing  Required  For  At  Least  One 


The  data  initially  collected  from  the  OEM  is  reviewed  by  the 
NAVAIR  SMEs  and  deemed  to  be  insufficient  to  submit  a  certification  request  package. 
The  PMA  requests  the  OEM  provide  additional  data  and/or  T  and  E  facilities  conduct 
tests  to  obtain  required  information.  The  tests  are  conducted  and/or  additional  data  is 
received  from  the  technology  developer  to  supplement  the  inadequate  data  packages.  This 
scenario  was  shown  in  Figure  13  and  described  below: 

•  Technology  developer  delivers  the  payload  to  PMA-263 
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•  PMA-263  determines  the  applicable  certification  and 
collects  data  from  the  developer 

•  Technology  developer  provides  requested  data 

•  PMA-263  forwards  data  to  SMEs  for  review 

•  SMEs  determine  that  data  is  insufficient  and  additional 
data/testing  will  be  required 

•  PMA-263requests  more  data  from  the  technology 
developer 

•  PMA-263  requests  T  and  E  facilities  to  conduct  tests  to 
collect  more  data 

•  Technology  developer  provides  additional  data 

•  T  and  E  facilities  provide  test  reports 

•  PMA-263  forwards  additional  data  to  SMEs  for  review 

•  Repeat  Steps  5-8  until  SMEs  determine  that  data  is 
sufficient 

•  PMA-263  develops  a  data  package  to  support  the 
certification  application  and  forwards  to  the  Approval 
Authority 

•  Approval  Authority  certifies  the  payload 

•  PMA-263  fields  the  platform  with  the  new  payload 
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Figure  13:  Additional  Testing  Use-Case 


Requirement 


(3)  Interim  Approval  Requested  For  At  Least  One 


The  data  initially  collected  from  the  OEM  is  reviewed  by  the 
NAVAIR  SMEs  and  deemed  to  be  insufficient.  Due  to  schedule  constraints,  the  PMA 
decides  to  forego  additional  testing  and  pursues  a  waiver  or  interim  certification.  This 
scenario  was  shown  in  Figure  14  and  described  below: 

•  Technology  developer  delivers  the  payload  to  PMA-263 

•  PMA-263  determines  the  applicable  certification  and 
collects  data  from  the  developer 
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•  Technology  developer  provides  requested  data 

•  PMA-263  forwards  data  to  SMEs  for  review 

•  SMEs  determine  that  data  is  insufficient  and  additional 
data/testing  will  be  required 

•  PMA-263requests  more  data  from  the  technology 
developer 

•  No  additional  data  available  without  further  testing 

•  PMA-263  deems  that  the  compressed  schedule  cannot 
support  further  testing,  so  waivers/interim  approvals  will  be 
necessary.  PMA-263  develops  a  data  package  to  support 
the  waiver/interim  certification  application  and  forwards  to 
the  Waiver/ Approval  Authority 

•  Waiver/Approval  Authority  waives  or  provides  interim 
certification  of  the  payload 

•  PMA-263  fields  the  platform  with  the  new  payload 
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Figure  14:  Interim  Certification  Use-Case 


Warfighter 
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c. 


FUNDAMENTAL  OBJECTIVES  HIERARCHY 
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Figure  15:  RTP  Fundamental  Objective  Hierarchy 


The  core  purpose  of  the  system  was  to  reduce  the  time  it  takes  to  obtain  fielding 
approval  of  a  new  payload  and  STUAS  combination.  Currently,  the  main  obstacle  was 
ensuring  that  all  statutory  and  regulatory  requirements  have  been  addressed  while  still 
meeting  the  required  fielding  timeline.  These  requirements  exist  to  reduce  the 
performance,  safety,  and  cost  risk  involved  in  fielding  a  weapon  system  or  air  platform 
into  the  DoN  inventory.  Any  effort  to  reduce  the  time  taken  to  prepare  for  and  make  a 
fielding  decision  must  include  identifying  risks  associated  with  interim  approvals  and 
balancing  the  benefits  with  the  risks.  The  fundamental  objective  was  decomposed  into 
progressively  more  concrete  objectives  until  they  formed  the  measures  of  effectiveness 
and  the  system  technical  performance  measures.  The  fundamental  objectives  are  detailed 
below  and  shown  in  Figure  15. 
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•  Minimize  time  to  comprehensively  integrate  new  capability  into  DoN 
o  Minimize  time  to  address  statutory  and  regulatory  requirements 

■  Minimize  time  to  Determine  Needed  Certifications 

•  Time  to  determine  needed  certifications  value  curve 

■  Minimize  time  to  address  needed  certifications,  including  time  to  collect 

additional  data. 

•  Time  to  process  waivers/interim  value  curve 

•  Time  to  obtain  full  certification  value  curve 
o  Minimize  risks 

■  Minimize  interim  approvals 

•  Percentage  of  interim  approvals  value  curve 

1.  Value  Curves 

At  the  bottom  of  the  fundamental  objectives  hierarchy  are  the  value  curves  that 
capture  the  PMA’s  normalized  weighting  of  the  utility  value  of  each  of  the  bottom  level 
objectives.  They  are  represented  by  both  stand-alone  functions  that  describe  usefulness 
on  a  continuum  from  most  utility  to  no  utility,  and  normalizing  weighting  factors.  The 
weighting  factors  defined  the  importance  of  each  bottom-level  objective  to  achieving  the 
PMA’s  goal.  Together,  the  utility  values  and  weights  formed  value  products  that,  when 
summed,  allowed  the  direct  comparison  of  different  system  designs. 

Because  the  importance  of  starting  with  the  end  in  mind  (Covey  2004  95)  for 
planning  the  execution  of  a  complex  set  of  certifications  and  approvals,  along  with  the 
conviction  that  a  well-formed  system  should  easily  expedite  planning,  the  time  to 
determine  needed  certifications  was  weighted  at  15%.  The  relative  impact  of  risk  due  to 
interim  approvals  was  determined  to  also  be  15%.  The  main  source  of  delay,  and 
currently  the  driving  force  in  accepting  unidentified  risk,  has  been  the  time  it  takes  to 
address  the  required  certifications  and  approvals.  The  time  to  obtain  interim  approvals 
and  the  time  to  obtain  full  certifications  were  both  set  at  35%.  This  weighting  strongly 
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favored  strategies  that  utilize  payloads  comprised  of  components  that  have  already  been 
certified  and  approved. 

The  primary  objective  of  the  RTP  was  to  quickly  integrate  a  new  capability  into 
the  DoN  System.  Because  of  this,  the  process  became  less  attractive  as  more  time  passed 
the  capability  can  be  fielded.  This  resulted  in  value  curves  with  a  linear  shape  and 
weightings  obtained  from  the  PM  A,  as  depicted  in  Figure  15. 

2.  Measures  of  Success 

Analysis  of  the  fundamental  objectives  expressed  by  the  stakeholders  in  section 
2.3  resulted  in  the  identification  of  measures  of  effectiveness  (MOE)  and  performance 
(MOP)  by  the  RAIN  Team. 

a.  MOE 

To  encourage  utilization  of  the  designed  product,  it  was  important  to 
identify  the  users’  ultimate  objective:  rapidly  field  a  new  payload.  For  this  project,  the 
mission  to  be  accomplished  was  the  fielding  of  a  new  capability  to  the  warfighter.  To 
successfully  support  this  objective,  the  RAIN  project  developed  a  process  that  was  able  to 
facilitate  comprehensive  integration  of  a  new  payload  into  the  DoN  System.  This  resulted 
in  the  following  MOE: 

•  MOE:  Probability  of  addressing  all  statutory  and  regulatory  requirements  to 

enable  fielding  of  a  new  payload  to  the  warfighter  in  18  months. 

b.  MOP 

The  identified  MOE  identified  above  was  decomposed  into  the  following 
MOPs  and  subsequent  Technical  Performance  Measures  (TPM). 

•  MOP:  Number  of  interim  Technical  Certifications 

o  TPM  -  %  requirements  that  need  interim  approval 

•  MOP:  Median  time  to  gain  approval  to  field  a  new  capability 
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o  TPM  -  Number  of  months  from  platform  integration  of  new 
capability  until  approval  to  field  newly  configured  STUAS 

D.  ARCHITECTURE  DEVELOPMENT 

The  RTP  architecture  section  was  an  overview  of  the  RTP  structure.  Appendix  C 
provides  the  complete  RTP  architecture,  which  consists  of  component  structure, 
Functional  Flow  Block  Diagram  (FFBD),  and  Integration  Definition  for  Function 
Modeling  (IDEFO)  for  the  entire  system  function. 

The  proposed  RTP  system  baseline  architecture  was  designed  allowing  payload 
integration  to  be  a  flexible  and  adaptable  SE  process.  The  CORE®  architecture 
development  program  by  Vitech®  was  utilized  to  plan  the  system  architecture,  creating  a 
top-down  design  to  identify  the  new  payload  integration  process. 

The  RTP  baseline  architecture  was  developed  from  an  evaluation  of  the  functional 
requirements  derived  from  the  problem  statement  and  scope.  This  design  was  analyzed 
and  compared  against  the  system’s  architecture  needs  to  identify  tradeoffs  between  the 
functional  requirements  and  the  desired  integration  and  fielding  timeline.  The  current 
PMA-263  UAS  certification  process  was  used  to  determine  the  additional  architectural 
components  needed  to  support  the  RTP  functional  and  operational  capabilities. 

The  functional  architecture  defines  the  logic  of  what  will  be  done  by  the  system. 
According  to  Buede,  not  only  does  it  contain  “...a  hierarchical  model  of  the  functions 
performed  by  the  system...”  (Buede  2009  194-211,  213),  but  its  development  must 
comply  with  exit  criteria  that  require  “...the  coherent  matching  of  the  input/output 
requirements  with  the  functions  and  items  in  the  functional  architecture... in  increasing 
layers  of  detail,  so  the  exit  criterion... will  be  applied  with  each  completion  of  a  layer  of 
detail.”  (Buede  2009  194-211,  213).  This  starts  with  leveraging  the  concept  of  operations 
to  define  the  system  boundaries  and  interfaces  with  external  systems,  and  continues  to 
decompose  the  system  until  sufficient  detail  was  obtained  to  be  able  to  design  the  system 
components. 
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The  physical  architecture  defines  what  will  perform  the  functions  detailed  in  the 
functional  architecture.  A  RTP  physical  architecture  was  not  fully  developed,  or  utilized, 
because  the  system  was  primarily  logical  and  would  employ  simple  forms  and  diagrams 
as  the  physical  components. 
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Figure  16:  RTP  External  Systems  Diagram 


The  RTP  External  Systems  Diagram,  shown  in  Figure  16,  shows  the  external 
system  interfaces  utilized  by  the  RTP.  The  systems  located  within  the  box  are  those 
impacted  by  the  RTP.  The  environment  outside  of  the  box  is  composed  of  systems  that 
impact,  but  are  not  affected,  by  the  RTP.  The  out-going  arrows  identify  systems  that  are 
impacted  by  the  RTP,  while  those  that  impact  the  RTP  are  identified  with  in-coming 
arrows. 

The  RTP  architecture  was  the  product  of  an  iterative  process  of  definition, 

decomposition,  and  refinement.  The  RTP  External  Interfaces  Diagram  (Figure  11)  was 
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the  result  of  extensive  analysis  of  the  requirements,  concept  of  operations,  fundamental 
objectives,  and  system  boundary  interfaces.  The  diagram  shows  that  the  RAIN  Project 
will  have  to  interact  with  PMA-263  for  system-related  requirements  and  in  developing 
the  RTP  to  provide  them  with  the  fielding  decision  support  package;  certification 
technical  authorities,  for  both  direction  on  the  statutory  and  regulatory  requirements  and 
for  certification  reviews  for  approval;  and  the  T  and  E  facilities  to  determine  the 
performance  of  the  system  relative  to  certification  requirements.  The  RPT  inputs,  outputs, 
triggers,  and  mechanisms,  more  clearly  shown  in  Figure  17,  which  was  used  extensively 
during  the  functional  decomposition. 
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Figure  17:  RTP  Inputs/Outputs  with  External  Systems 


2.  Architecture  Design 

The  RTP  was  designed  to  obtain  a  fielding  decision  approval  within  18  months, 
while  managing  the  risk  of  meeting  a  rapid  timeline.  RTP  supports  and  brings  order  to  the 
process  of  integrating  a  new  payload  combination  on  a  modular  STUAS  by  determining 
the  complete  set  of  required  certifications;  and  identifying  the  options  and  risks  to 
pursuing  full  certifications,  interim  certifications,  or  a  combination  of  the  two  (2).  The 
RTP  involves  the  following  steps: 

•  Determining  which  certifications  are  required  for  the  payload  of  interest. 

39 


•  Collecting  the  required  support  documentation  and  analyzing  for  completeness 

•  Employing  T  and  E  as  needed  to  answer  all  open  questions 

•  Identifying  and  addressing  the  residual  risks 

•  Assembling  data  packages 

•  Developing  certification  request  packages 

•  Requesting  full  or  interim  approval  for  each  required  certification 

3.  RTP  Functional  Architecture 
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Figure  18:  RTP  Functional  Hierarchy 


The  RTP  Functional  Hierarchy  in  Figure  18  was  produced  following  the  clear 
definition  of  the  system  boundaries  and  interfaces  during  the  functional  decomposition. 
This  functional  hierarchy  was  extended  to  a  sufficient  level  of  detail  to  construct  the 
schedule,  cost  models,  and  user  tools;  including  check  lists  and  flow  diagrams.  The  useful 
hierarchy  depth  was  decomposed  to  three  (3)  levels  and  shows  the  decomposition 


40 


relationships  of  the  five  (5)  basic  functions  Figure  19  of  the  RTP  system,  and  details  the 
sub-functions. 


Figure  19:  RTP  Top  Level  Functions  (IDEFO) 


The  top-level  functions  were  determined  by  analysis  of  the  top  level  input,  output, 
interface,  and  functional  requirements,  as  well  as  the  fundamental  objectives  and  system 
boundary  interfaces.  The  requirements  were  derived  from  the  functional  objective 
hierarchy,  system  boundary  and  interface  definitions,  and  the  concept  of  operations. 

Once  the  first  level  of  functions  (including  inputs,  outputs,  triggers,  and 
mechanisms)  were  defined,  the  next  levels  were  determined  through  logical 
decomposition  and  analysis  of  the  top  level  requirements,  and  analysis  of  the 
fundamental  objectives  hierarchy.  In  each  level,  the  requirements  were  allocated  to 
functions  to  ensure  that  all  requirements  were  met  and  needed.  This  was  continued  until 
sufficient  detail  was  developed  to  build  the  simulation  models  and  user  tools. 
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III.  COMPONENT  ATTRIBUTE  INVESTIGATION 


The  Team’s  research  into  the  statutory  and  regulatory  requirements  resulted  in  the 
identification  of  potential  certifications,  as  shown  in  Figure  20  that  would  need  to  be 
obtained  prior  to  fielding  a  new  payload.  The  RTP  shall  satisfy  the  necessary  DoN 
System  requirements  by  obtaining  the  applicable  certification(s). 


Figure  20:  Applicable  Certification  Categories 


The  certifications  were  separated  into  four  (4)  categories,  in  accordance  with  the 
System  Requirements  identified  earlier: 

•  Safety 

•  Airworthiness 

•  System  Safety 

•  Laser 

•  Weapon 

•  Battery 
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•  Range  Safety 

•  E3 

•  Security 

•  Information  Assurance  (IA) 

•  Anti-Tamper  (AT) 

•  Selective  Availability  Anti-Spoofing  Module  (SAASM) 

•  Clinger-Cohen  Act  (CCA) 

•  Interoperability 

•  Spectrum 

•  Common  Datalink  (CDL) 

•  Interoperability 

•  Compatibility 

•  Environmental 

•  Test  and  Evaluation  (T  and  E) 

A  brief  overview  of  each  certification  with  details  of  the  artifacts  needed  for  a 
complete  data  package  is  provided  in  Appendix  H. 

A.  RESEARCH  MATRIX 

The  RAIN  project  research  matrix  shown  in  Figure  21  and  further  detailed  in 
Appendix  D,  was  a  living  document  used  to  capture  and  summarize  information  about  the 
statutory  and  regulatory  requirements  required  to  support  a  fielding  decision.  The  gray 
and  blue  fields  contain  the  name  of  each  certification  and,  where  applicable,  each  sub- 
certification;  the  person  assigned  to  conduct  the  research;  whether  it  was  in  scope;  the 
type  of  requirement  (statutory  or  regulatory);  the  top  level  actively-used  guiding 
instruction  and  supporting  guidance(s);  the  approving  authority  office  or  organization; 
whether  interim  approval  or  waivers  were  allowed;  what  office  could  grant  waivers  or 
interim  approvals;  a  listing  of  the  required  documentation;  whether  testing  was  required 
to  support  the  certification  approval;  the  best  case  (Low),  most  likely  case  (Med)  and 
worst  case  (High)  values  for  cost,  lead-time,  and  certification  activity  duration;  and 
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explanatory  notes.  Below  the  summary  data  fields  is  the  table  of  multipliers  used  for 
converting  point  estimates  into  triangular  distributions  for  the  model  (based  on  the  SME’s 
assessment  of  the  risk  associated  with  the  estimate)  (Raymond  1999,  147-156).  The  un¬ 
shaded  fields  to  the  right  of  the  summary  data  detailed  the  “Risk  Simulator”  models  for 
the  all-inclusive  generic  cost,  as  well  as  the  time  reduction  strategy  costs  for  each  DRM 
use  case.  The  green  and  brown  fields  hold  the  reference  data  for  the  triangular  input 
distributions  and  the  tan  fields  hold  the  summation  expressions  as  well  as  the  reference 
data  for  the  statistical  output  collection. 
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Figure  21 :  RAIN  Research  Matrix  and  Cost  Model  Snapshot  (Detail  Shown  in 

Appendix  D) 


B.  PREREQUISITE  CERTIFICATIONS 

During  the  investigation  of  the  above  components,  the  RAIN  Team  discovered 
that  all  certifications  could  not  be  pursued  concurrently;  some  certifications  require  the 
completion  of  others  before  they  can  be  obtained.  The  following  certifications  were 
identified  as  having  prerequisites,  with  specific  relationships  documented  in  a  tailored 
schedule  in  Appendix  I: 
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•  T  and  E 

•  Airworthiness 

•  WSERB 

•  IA 

•  Safety 

•  E3 

Figure  22  provides  a  graphical  representation  of  the  order  in  which  the  applicable 
certifications  should  be  pursued: 


Figure  22:  Prerequisite  Certifications 


For  example,  Airworthiness  certification  cannot  be  issued  until  Safety,  Air-Ship 
Integration  (if  applicable),  Environmental,  and  E3  are  first  obtained. 
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IV.  PROCESS  TRADE  STUDY 


A.  MODELING  AND  SIMULATION  (M  AND  S)  OVERVIEW 

“All  models  are  bad,  but  some  are  useful”  (Box,  G.  E.,  Draper,  N.  R  1987). 
Because  of  the  complicated  interactions  between  the  sub-processes  involved  in  approving 
the  integration  of  a  new  payload  onto  a  STUAS  and  approving  the  use  of  the  new  system, 
M  and  S  was  used  to  represent  and  test  the  overall  integration  approval  process  schedule 
and  associated  cost.  Models  assisted  in  understanding  the  current  sub-processes  of 
individual  certifications,  the  generic  process  of  addressing  all  certifications,  the  impact  of 
tailoring  to  match  the  DRMs,  and  the  RTP  timeline  reduction  options.  The  simulations 
were  used  to  verify  the  model  of  the  generic  process  and  to  project  the  performance  of  it, 
as  tailored  to  match  the  DRMs,  and  as  tailored  to  implement  timeline  reduction  strategy 
options.  For  each  DRM  of  payload  type  and  run  the  desired  process  would  be  one  that 
addresses  all  required  certifications  or  accreditations  within  the  desired  schedule  without 
incurring  unacceptable  risk.  In  the  event  that  more  than  one  process  met  these  provisions, 
then  the  one  most  closely  optimized  the  criteria  from  the  fundamental  objectives 
hierarchy  (Figure  27)  would  be  chosen.  The  DRM  scenarios  were  chosen  by  PMA-263  to 
cover  the  most  likely  upcoming  payload  and  STUAS  integrations.  The  Team’s  work 
elicited  from  SMEs  the  probable  schedule,  cost,  and  risks  the  program  manager  would 
need  to  understand  to  make  an  informed  decision  regarding  the  available  options 
presented.  The  available  options  included  varying  the  order  the  certifications  were 
addressed,  within  the  constraints  of  the  order  dependency  prerequisites;  and 
implementing  or  not  implementing  timeline  reduction  strategies  of  subsystem  interim  or 
previous  certifications.  The  results  were  used  to  show  the  relationship  between  schedule 
compression  and  cost,  associated  with  the  application  of  timeline  reduction  strategies  to 
the  process.  Risk  expansion  related  to  schedule  compression  was  examined  further  in  the 
Risk  Section  of  this  paper 
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B. 


GENERIC  MODEL  DEVELOPMENT 


The  time  model  was  built  in  iGrafx®  because  of  how  well  it  represents  process 
flows  and  utilized  data  gathered  in  the  required  certifications  research  matrix  (Appendix 
D).  This  data  was  used  to  model  each  certification  sub-process  cost  and  schedule  as 
simple  triangular  distributions  (Following  (Raymond  1999  147-156)).  In  order  to  explore 
the  theoretical  upper  and  lower  bounds  on  the  time  required  to  complete  all  of  the 
certifications  models  were  built  for  pursuing  certifications  in  an  all  serial  flow  and  in  an 
all  parallel  flow.  These  obviously  produced  results  that  were  outside  of  what  would  either 
be  allowed  (all  parallel)  or  desired  (all  serial).  Prior  to  the  iterative  corrections  involved 
in  building  the  final  generic  model;  an  all  serial  flow  took  a  mean  of  109  months  and  an 
all  parallel  flow  took  a  mean  of  16  months  (reference  the  first  four  slides  in  Appendix  F). 
The  dependency  prerequisite  relationships  among  the  various  certifications,  discussed 
earlier,  were  used  to  build  and  order  the  generic  model  from  the  individual  ‘building 
block’  certification  sub-process  model  representations.  The  final  generic  model  used 
parallel  flows  where  ever  possible,  and  not  proscribed  by  dependency  prerequisite 
relationships,  instead  of  serial  in  order  to  minimize  overall  schedule  time  to  address  all  of 
the  certifications.  Additional  SME  input  was  used  to  iteratively  refine  the  generic  model 
until  it  appropriately  captured  the  flow,  prerequisite  relationships,  and  durations,  as 
shown  in.  Figure  23. 
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S^Start 


Series  in  conjunction  with  Parallel  efforts 

- ]  / 


Figure  23:  Generic  RTP  certifications  process  flow  model  for  cycle  time 

(for  LASER  Designator  Run  Number  1). 
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The  generic  cost  model  was  built  in  Excel  alongside  the  Research  Matrix 
(Appendix  D).  The  cost  ranges  of  Low,  Most  Likely,  and  High  were  used  as  parameters 
to  form  triangular  distribution  inputs  in  Risk  Simulator®  (Figure  24).  The  cost  model  was 
built  in  Risk  Simulator®  because,  as  a  Microsoft  Excel®  add-on,  it  allowed  the  cost 
model  to  be  built  fairly  quickly  and  outputted  nearly  complete  statistical  representations 
of  the  results,  including  histograms,  which  required  very  little  additional  work  for 
analysis.  The  output  for  the  generic  model  was  defined  as  the  sum  of  all  the  costs  from 
each  of  the  individual  distributions,  and  contained  the  control  tests  for  successful 
completion. 
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Figure  24:  Cost  Model  Simulation  Input  Distribution  example. 


The  generic  model  represented  the  case  where  all  possible  certifications  and 
approvals  were  required.  This  was  used  to  simulate  the  time  involved  in  the  worst  case 
successful  single  start  approval  process.  The  results  of  simulating  the  process  with  the 
generic  all  inclusive  model  showed  that  despite  being  built  from  inputs  of  triangular 
distributions  the  output  was  approximately  normal,  as  shown  in  Figure  25  and  Figure  26. 
This  reflected  the  assertion  of  the  central  limit  theorem  which  states  that  for  independent 
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and  identically  distributed  real  variables  (RV)  the  distributions  for  the  sum  of  the 
variables,  and  also  the  mean  of  the  RVs,  are  approximately  normal  when  the  number  of 
samples  (n)  is  large  enough  (>  30)  (Devore  J.L  2008,  Sect.  5.4).  The  real  values  in  this 
case  came  from  43  independent  triangular  value  distributions.  The  normal  distribution 
results  facilitated  communication  with  SMEs  about  the  models. 


Summary  for  CycleTime  (Hrs)  Baseline  with  PreReq's 

ActivityName  =  End 


95%  Confidence  Intervals 


Andereon-Dariing  Nomnality  Test 

-  A-Squared 

0.36 

^^Value 

0.438 

Mean 

180.24 

StDev 

15.85 

Variance 

251.15 

Skewness 

0.218344 

Kurtosis 

0.241126 

N 

500 

Minimum 

136.98 

1st  Quartile 

168.89 

Median 

180.67 

3rd  Quartile 

189.91 

Maximum 

241.25 

95%  Confidence  Interval  For  Mean 
178.85  181.63 

95%  Confidence  Interval  For  Median 
178.37  182.45 

95%  Confidence  Interval  For  StDev 
14.92  16.90 


Figure  25: 


Graphical  Statistical  Summary  of  Generic  Model  overall  cycle  time. 
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Process  Capability  of  CycleTime 


Process  Data 

LB 

0 

Target 

52 

USL 

78 

Sample  Mean 

180.24 

Sample  H 

500 

StDev(Within) 

16.1481 

StDev(Overall) 

15.8478 

□  35  70  105  140  175  210  245 


Within 
—  —  Overall 


Potential  (Within)  Capability 

Cp 

* 

CPL 

* 

CPU 

-2.11 

Cpk 

-2.11 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

-2.15 

Ppk 

-2.15 

Cpm 

0.07 

Observed  Petfomnance 

Exp.  Within  Petfomnance 

Exp.  Overall  Petfomnance 

%  <  LB 

0.00 

%  <  LB 

* 

%  ■=:  LB 

* 

%  >  USL 

100.00 

%  >  USL 

100.00 

■  C7  %  >  USL 

100.00 

%  Total 

100.00 

%  Total 

100.00 

8b  lotal 

iuu.no - 

100%  Exceed  78  week  limit 


Figure  26:  Capability  Analysis  Chart  for  Generic  Model 

(with  upper  specification  limit  of  78  weeks.) 


The  mean  cycle  time  of  the  worst  case  scenario  is  well  above  the  desired  cycle 
time  upper  limit  of  78  weeks,  with  a  mean  cost  (Figure  27)  of  $1.8M.  Expert  opinion 
verified  these  results,  confirming  that  the  model  accurately  represented  the  process.  This 
led  to  the  development  of  the  proposed  “to-be”  baseline  process  models  (Dam  2006)  for 
each  DRM  scenario. 


52 


■Ilki  :  ;FV12  f  IQ  Fur  D-ui-iL|  A I  C^tU:  F,iik  iirru’ uLu-  FuiuLdzJ. 

1 4*  4*  -S4  -i7+ <»  ^  M  M  1j  V -j  ^  j  l1  (J  1  j  C1  CJ 


vp*  | Le41-T BP  i  ■'I 
csm  |ea- 


M  i.Kihl-  CwtaNy  ■-;  |  LU  ■_1I_U 


H  n-L’n  ■r-.viS'v  Esri  * 

“jj>: 

'  FI  T*  - 

[71 


LK»n  A -Ate  a  i]i  -*-||  J-CiY*  i 


V-Ai* 

RiA1!1.  Ik1-  TilT]  ■  RfE 

acji  i-+:-+i-:i  0>  Li-ifi.ij 

IL-iflrcml  Hhh  l£4Q  Ui  1342.12  Cti^vi 

El*it  ItE:  It  2&1  17 

!fh"w  o  2C  C  4.1 

f'-V’Bb*:  U.lES-E-  hur  -£i.-j6  C.33[ 


rasi.i  ic 


2  jkjl^irTAj 


HiillSI  Jill  Rl.ju 

rmrtw 

SnFjl-Ui-Lii 


Da-j  -ild-lk-  Ifi-jiiv:! 

Fata 

U  pitrc 


3D  ^  -  i,  V£  'ii  fe'  v  -  *i  -  k+  ffl  a 

H-'iJ  Vkw 

.:3 

F>r 

n  rr ri -V  Trrfr 

1(K*Xl 

Mlj 

l.&tDCGII 

S’s'tSsn 

l.LUhWUU 

Slur  ;  1  ij :l  Duvwtsa* 

I'jiiflnFri  d  Vmnw 

n  I’-MB 

MWIJYi 

ZFS4  H& 

PA-jTim 

RjiV- 

1.+T7.WM 

(I  3DM 

Kij  Liu  j 

a  ::-  ed 

1.1^2  d  ■Mh 

7Ii!i  Fij .  i: 

2,  MB  SMB 

kwlw  hT-v  -‘K-.W-.v  d  y:h  ttrttancsi 

lu&m 

i1  d-d  bri-dy 

^  j'jijiJj-J  tk-.  i-.li-n  1 1  ul 


Ucn  Fftar 

■  S  fJinw  nl  rt«N 

Shrrw.'  nrJy  Hit-a  Mrt^vwi 

i  LV."  LI  I  J."  ‘JdJ  V.lUl  II 

'SjlkiiLe 

F'i-.l;  ji-.Hi  i.-v-.l  .  j-.'J  .-j -Ldku!  jIl  Uk-uiu.  |  \Ly-jr]  % 

fihntvtiH  rrJrvrnn  KL»ri.>-Hr.>  i  on  -twi  h  Akwirar- 
7?1  Mm  i^l  hWHun  FI  '  jMUiwIiln  [""  3rs  ;-i i ■  "r:  in 

&tlDW  DKJr-tfq 

OitaLXAKh  (I  -*-j]  Qj'iEJuhjl-  -4  [*-  SjIi-jLf-j  -1 

Dijpk/  CWi'j-J 

I™"  AIaa^  Frh-Ti*  V'.Sncbwu  On  Tr-fi  |  CIiuhAI 

.  E-.SII  J  .llj^.l'.lll  .'.lll  I  Lh.lil1.  I  K'ili  ill  JL  nil 


Figure  27:  Cost  Statistical  Analysis  for  Generic  Model 


C.  MODELS  DEFINTIONS  -  RAIN  PROJECT  CASE  STUDIES 

Although  five  (5)  payloads  were  earlier  identified  as  components  typically 
integrated  by  PMA-263,  the  identical  required  certifications  for  RADAR, 
Communications/Data  Relay,  and  Active  EW  enabled  their  consolidation  into  one.  The 
remaining  DRMs  of  LASER  Designator,  Passive  EW,  and  Active  EW  payloads  were 
determined  by  PMA-263  representatives  to  require  the  certifications  identified  in  Table  1. 
For  each  certification  Green  means  the  certification  was  required,  while  Red  or  Blue 
means  the  certification  was  not. 

Three  (3)  scenarios  with  different  integration  complexity  were  utilized  for  each 
DRM  payload:  Simple,  Complex,  and  Mature  Payload.  In  a  Simple  Integration,  the 
payload  has  little  interface  with  the  platform;  all  components  needed  for  operation  were 
self-contained  within  the  payload.  In  a  Complex  Integration,  the  payload  interfaces  with 
the  platform,  requiring  the  use  of  the  existing  components  (e.g.,  battery,  datalinks,  etc.). 
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In  a  Mature  Payload  Integration,  the  payload  was  delivered  with  the  majority  of  the 
required  certifications  already  obtained. 

Models  for  each  of  the  DRM  payloads  were  then  formed  from  the  generic  model 
by  removing  unneeded  certification  sub-processes. 


Selective  Availability  Anti- 
Spoofing  Module  (S  AASM) 


Table  1 :  DRM  Run  Definitions 

(Red=  Certification  Required,  Green/Blue=Certification  Not  Required) 


Timeline  reduction  strategies  were  formulated  to  exploit  the  allowance  for  some 
of  the  certifications  to  be  either  interim  or  previously  completed  and  are  summarized  in 
Table  2.  While  the  RTP  starts  after  the  delivery  of  a  properly  operating  payload,  the 
PMA-263  decides  which  payloads  are  developed  and  can  insist  that  certain  subsystems  in 
the  payload  be  ones  that  were  previously  certified  in  order  to  negate  the  need  for  the 
certifications  that  would  drive  the  fielding  decision  beyond  18  months.  Whether  this  was 
done  would  be  in  the  payload  design  description  data  provided  with  the  payload.  This 
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was  a  subset  of  the  benefits  realized  by  using  standard  parts,  but  may  not  be  realizable  on 
a  regular  basis  until  the  industrial  base  for  the  required  small  and  ruggedized  subsystems 
becomes  more  mature.  Due  to  the  undesired  nature  of  waivers,  the  option  of  using 
previously  certified  sub-systems  or  components  to  bypass  some  of  the  long  duration 
certifications  was  introduced  instead  of  considering  waivers.  The  time  distributions  for  all 
of  the  full  certifications  are  in  the  research  matrix  (Appendix  D  columns  Q  through  V) 
and  are  the  sums  of  the  lead  time  from  request  to  start  of  work  on  the  certification  and  the 
duration  to  actually  process  and  provide  findings  (approval/rejection).  The  time 
distribution  changes  for  each  timeline  reduction  strategy  are  listed  in  Appendix  G  section 
1,  and  represent  significant  reductions  from  the  baseline  full  certification  values. 

The  individual  options  for  shortening  the  certification  timelines  were  aggregated 
into  two  (2)  alternative  strategies:  intermediate  risk  timeline  reduction  (IRTR)  and  low 
risk  timeline  reduction  (LRTR).  This  could  have  been  done  for  any  combination  full, 
interim,  previous,  or  waived  certifications  by  simply  changing  the  time  distribution  in  the 
definition  of  the  certification(s)  of  interest,  rerunning  the  simulation,  exporting  the  data 
Minitab®,  conducting  statistical  analysis,  capturing  the  new  flow  diagram  (showing  the 
new  distribution  values),  capturing  the  statistical  analysis  results,  and  organizing  into  a 
brief.  All  this  takes  about  20  minutes  for  each  model  change.  This  was  not  done  for 
expediency  reasons  since  we  were  already  up  to  27  runs  (9  hours)  from  the  three  DRMs 
of  three  runs  each  and  three  different  strategies.  If  it  had  been  done  we  would  be  20 
minutes  x  3  DRMs  x  3  runs  x  a  minimum  of  (12+1)  simple  individual  changes  (Appendix 
G  Table  2)  =  39  hours  to  just  collect  the  data.  The  use  of  Minitab®  and  DOE  could  be 
used  in  the  future  to  extend  our  work  to  optimize  the  RTP  for  specific  DRMs  and  run 
types.  The  IRTR  strategy  was  composed  of  pursuing  interim  certification  or  approvals  for 
Battery,  IA,  Spectrum,  and  JITC;  and  a  Category  3  IFC,  while  shifting  OT  during  initial 
fielding.  Interim  approvals  accept  more  risk  than  full  certifications  or  using  previously 
certified  subsystems,  but  less  risk  than  skipping  it  altogether,  leading  to  this  strategy 
being  called  “Intermediate  Risk  Timeline  Reduction.”  The  LRTR  strategy  was  comprised 
of  using  previously  certified  or  approved  data  links,  batteries,  transmitters,  and  GPS 

receivers  while  pursuing  a  Category  Three  (3)  IFC  and  conducting  a  combined  DT/OT. 
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In  comparison  to  using  unproven  subsystems,  using  a  previously  certified  item  is  low 
risk,  thus  the  name  “Low  Risk  Timeline  Reduction.”  A  summary  of  the  strategies  are  in 
Table  2;  ‘FULL’  means  full  certification  is  pursued,  ‘Interim’  means  a  interim 
certification  is  pursued,  ‘Previous  Cert’  means  that  certification  was  completed  previous 
to  the  triggering  subsystem  being  used  in  this  payload.  These  strategies  were  then  applied 
to  the  baseline  model  of  full  certifications  for  each  DRM  run  cases. 


CERTIFICATION 

IRTR 

LRTR 

CDL 

FULL 

Previous  Cert 

IFC 

CAT  3 

CAT  3 

Battery 

Interim 

Previous  Cert 

IA 

Interim 

FULL 

Spectrum 

Interim 

Previous  Cert 

T  and  E 

OT  in  fielding 

Joint  DT  OT 

JTIC 

Interim 

FULL 

SAASM 

FULL 

Previous  Cert 

Table  2:  Timeline  Reduction  Strategies  Sub-Process 

(Changes  Summary) 


D.  RTP  MODELING  AND  SIMULATION  RESULTS 

The  baseline  (BL)  processes  were  found  to  take  longer  than  78  weeks  (18  months) 
on  average  for  most  of  the  DRM  scenario  runs,  as  shown  in  Table  3.  The  two  (2)  timeline 
reduction  strategies  (IRTR  and  LRTR)  were  then  applied  to  each  baseline  run  definition 
from  each  DRM.  Simulation  showed  that  both  strategies  brought  the  mean  time  to 
complete  all  of  the  required  certifications  to  less  than  78  weeks  in  almost  all  runs,  with 
the  associated  risk  of  exceeding  the  time  limit  determined  through  statistical  analysis. 
These  satisfactory  results,  summarized  in  Table  3,  reinforced  the  Team’s  resolve  to  not 
use  waiver  because  of  the  corresponding  increase  in  risk. 
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Payload 


Laser 

Designator 


Passive  EW 


Active  EW 


Schedule  (wks) 


Chance  to  Exceed 
78  wks  (%) 


Cost  ($K) 


Table  3:  Mean  Simulation  Results 


The  source  statistics  for  Table  3  came  from  the  statistical  analysis  charts 
generated  in  Minitab®  for  all  27  scenarios.  Examples  of  these  charts,  shown  in  Figure  28, 
Figure  29,  and  Figure  30,  show  the  cycle  time  statistics  resulting  from  the  application  of 
IRTR  to  run  2  for  the  Passive  Electronic  Warfare  payload.  The  full  collection  of  the 
statistical  analysis  charts  for  all  scenarios  is  collected  in  Appendix  H.  Because  the 
number  of  different  certifications  involved  in  the  27  scenarios  shown  in  Table  3  varied 
from  a  high  of  36  down  to  a  low  of  8,  the  effects  of  the  central  limit  theorem  varied  as 
well.  This  variance  manifested  in  the  distributions  for  schedule  appearing  to  be  normal  in 
a  few  cases,  log  normal  in  several  cases,  and  triangular  in  a  few  cases;  in  proportion  to 
the  number  of  certifications  involved  in  the  process. 
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Summary  for  CycleTime  (Wks)  Passive  EW  Run  2 IRTR 

Activit/Name  =  End 


Normal 


20  33  *0  SO 


TO  93 


95%  Confidence  Intervals 


Andercon  fading  Normality  T«t 

P-Value 

0.503 

Mean 

50.8% 

Stl>ev 

12.135 

Variance 

147.265 

Skewness 

0.062106 

Kurtosfa 

*0.281635 

N 

500 

Minimum 

20.066 

1st  Quaitile 

42,723 

Median 

50.694 

3rd  Quartile 

59,529 

Maximum 

84.569 

95%  Confidence  Interval  for  Mean 

49.770 

51,902 

95%  Confidence  Interval  for  Median 

49.169 

£2,238 

95%  Confidence  Interval  fdrStOev 

11.427 

12,938 

Figure  28:  Graphic  Statistical  Summary  of  overall  certification  cycle  time 

(for  Passive  Electronic  Warfare  Run  2  with  IRTR  applied.) 


Probability  Plot  of  CycleTime  (Wks)  Passive  EW  Run  2  IRTR 

Normal 


Mean 

50.84 

StDev 

12.14 

N 

500 

AD 

0.299 

P-Value 

0.583 

Figure  29:  Normality  Test  with  percentile  below  78  weeks 

(for  Passive  Electronic  Warfare  Run  2  with  IRTR  applied.) 
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Process  Capability  of  CycleTime  (Wks)  Passive  EW  Run  2  IRTR 


L-| - 1  |  I  I  I  !  I  I  I,  I  I  1 1  I  I  I  I  |  I  I  I  I  I  |  1  I  I  I  I  |  I  I 

□  12.5  25.0  37.5  50.0  62.5  75.0 


Process  Data 

LB 

0 

Target 

52 

USL 

73 

Sample  Mean 

50,3353 

Sample  N 

500 

StDev(Within) 

11,3421 

StDev(OveralQ 

12,1353 

Potential  (Within)  Capability 

Cp 

* 

CPL 

* 

CPU 

0.76 

Cpk 

0.76 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

0.75 

Ppk 

0.75 

Cpm 

0.71 

Observed  Performance 

36  <  LB  0.00 

Exp.  Within  Performance 

36  <  LB  * 

Exp.  Overall  Performance 
36  c  IP.  * 

1.26%  Exceed  78 

%  >  USL 

1.20 

%  >  USL 

1.03 

%  >  USL 

1.26 

week  limit. 

%  Total 

1.20 

%  Total 

1.03 

%  1  fl(5l 

-tzf. - 1 

Figure  30:  Capability  Analysis  chart  with  upper  specification  limit  of  78  Weeks 

(for  Passive  Electronic  Warfare  Run  2  with  IRTR  applied.) 


1.  Cost  Analysis 

Figure  31  shows  the  cost  models  for  all  of  the  DRM  scenarios.  A  much  larger  and 
more  readable  version  of  this  can  be  found  in  Appendix  F  at  the  beginning  of  the  RTP 
Cost  Simulation  section.  The  basic  triangular  cost  distribution  model  for  each 
certification  is  described  in  the  gray  fields  on  the  left  side  of  the  figure,  with  each  model 
in  a  single  labeled  column.  The  green  and  brown  fields  indicate  the  costs  included  in  that 
model.  Numbers  in  (or  next  to)  the  colored  field  are  multipliers  applied  to  the  basic 
triangular  distribution  from  the  gray  fields.  The  fractional  multipliers,  such  as  0.5  and 
0.25,  account  for  the  fact  that  interim  approvals  require  less  work  than  the  full 
certifications.  The  integer  multipliers,  such  as  4  or  2,  represent  the  number  of  times  that 
WSESRB  is  usually  repeated  in  the  modeled  scenario.  The  light  tan  fields  at  the  bottom 
hold  the  summation  logic  and  the  reference  to  the  Risk  Simulator®  data  collection  and 
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statistical  analysis  charts.  Further  detail  on  the  cost  analysis  can  be  found  in  Appendix  F. 
The  cost  distributions  varied  from  normal,  to  log  normal,  and  to  triangular  in  proportion 
to  the  number  of  cost  RVs  in  the  cost  summation  varying  from  36  to  8;  as  predicted  by 
the  central  limit  theorem. 


Figure  3 1 :  Cost  Models  for  all  Scenarios 


The  cost  results  from  the  simulations  are  summarized  in  Table  4,  which  shows 
that  the  cost  generally  goes  down  with  decreased  work.  The  LRTR  strategy  was  not  the 
lowest  cost  option  because  it  retains  OT  as  a  partial  cost  certification,  which  was 
relatively  expensive,  and  the  IRTR  strategy  moves  OT  to  preliminary  fielding.  Also,  the 
IRTR  strategy  results  in  less  cost  variability  because  OT,  which  has  relatively  high  cost 
variability,  was  conducted  before  fielding. 
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Payload 

Run 

Mean  Cost  i 

$K) 

Max  Cost  ($K) 

Max  -  Mean  ($K) 

BL 

IRTR 

LRTR 

BL 

IRTR 

LRTR 

BL 

IRTR 

LRTR 

LASER 

Designator 

1 

1,324 

859 

1,043 

2,210 

1,332 

1,694 

886 

473 

651 

2 

1,269 

437 

1,037 

2,156 

509 

1,687 

887 

72 

650 

3 

520' 

55 

287 

1,058 

97 

568 

538 

42 

281 

Passive  EW 

1 

1,726 

1,230 

1,387 

2,617 

1,689 

2,040 

891 

459 

653 

2 

1,233 

785 

1,022 

2,124 

1,239 

1,674 

891 

454 

652 

3 

520 

55 

287 

1,058 

97 

568 

538 

42 

281 

Active  EW 

1 

1,726 

1,230 

1,413 

2,617 

1,689 

2,063 

891 

459 

650 

2 

1,287 

817 

1,047 

2,183 

1,297 

1,698 

896 

480 

651 

3 

530 

60 

290 

1,069 

100 

570 

539 

40 

280 

Table  4:  Simulation  Results  for  Costs 


E.  MODELING  AND  SIMULATION  SUMMARY 

Modeling  and  simulation  was  used  to  explore  the  costs  and  schedule  times 
associated  with  different  designs  of  the  RTP.  Modeling  and  simulation  was  conducted 
using  both  Risk  Simulator®  (an  Excel  add-on)  for  cost  and  in  iGrafx®  for  the  time  to 
complete  certifications.  The  time  to  collect  and  present  the  results  of  the  certifications  to 
the  fielding  decision  maker  was  considered  to  be  insignificant  and  was  excluded  from  the 
model.  Modeling  started  with  conducting  all  certifications  all  in  parallel,  then  all  series, 
and  then  as  a  generic  series-parallel  hybrid  constrained  by  the  certification  dependency 
prerequisite  requirements.  Simulation  with  these  models  defined  the  outer  edges  of 
schedule  performance  when  pursuing  all  possible  certifications.  The  generic  model  was 
then  tailored  to  only  include  the  certifications  required  for  nine  different  DRM  run  cases. 
Each  of  the  DRM  models  were  then  modified  to  create  separate  models  that  reflected  the 
application  of  both  the  IRTR  and  LRTR  timeline  reduction  strategies  to  each  of  the  DRM 
run  cases. 

Simulation  with  an  early  model  with  all  certification  conducted  in  series  showed 
the  upper  mean  time  to  complete  at  approximately  109  months.  Simulation  with  an  early 
model  that  conducted  all  certifications  in  parallel  showed  that  lower  mean  time  to 
complete  was  approximately  16  months.  With  the  understanding  that  there  were  several 
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dependency  prerequisite  relationships,  this  indicated  that  it  was  unlikely  we  could 
complete  all  possible  certifications  within  18  months  without  some  certifications  be 
removed  or  reduced.  Simulation  with  the  generic  prerequisite  constrained  series-parallel 
hybrid  model  of  conducting  all  possible  certifications  the  mean  time  to  complete  was  45 
months.  Completing  all  possible  certifications  in  less  than  1 8  months  was  only  possible  if 
all  certifications  were  done  in  a  very  highly  parallel  manner,  and  the  required  dependency 
prerequisite  relationships  prevented  this. 

Simulation  with  models  based  on  the  generic  model  but  tailored  to  reflect  only  the 
certifications  required  by  each  DRM  run  case  show  that  the  mean  (baseline)  completion 
time  for  all  required  certifications  was  only  less  than  18  months  for  mature  (Run  3)  DRM 
run  cases  for  LASER  Designator  and  Passive  Electronic  Warfare  payloads;  timeline 
reduction  strategies  would  be  required  for  all  other  DRM  run  cases. 

Simulation  with  the  two  timeline  reduction  strategies  (IRTR  and  LRTR)  applied 
to  all  DRM  run  cases  showed  that  the  mean  time  to  complete  the  required  certification 
could  be  brought  to  less  than  1 8  months  in  most  cases  through  the  application  of  either 
timeline  reduction  strategies,  as  detailed  in  Table  3.  The  exceptions  were  the  DRM  run 
cases  for  both  Passive  EW  and  Active  EW  which  only  the  LRTR  strategy  reduced  the 
mean  completion  time  to  less  than  18  months. 

Cost  simulation  was  conducted  to  understand  the  impact  the  various  DRM  run 
cases  and  timeline  reduction  strategies  had  on  cost  and  to  support  budget  planning.  The 
cost  results  for  the  simulations  are  listed  in  the  left  most  column  of  Table  3  and  in  Table 
4.  The  baseline  full  certifications  process  consistently  costs  more  due  to  the  timeline 
reduction  strategies  reducing  the  work  involved.  While  the  application  of  the  IRTR 
strategy  consistently  cost  the  least,  it  was  at  a  higher  performance  risk,  as  detailed  in  the 
upcoming  Risk  analysis  section,  because  OT  was  pushed  out  to  initial  fielding. 
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V.  RAIN  RISK  ANALYSIS 


A.  OVERVIEW  OF  RISKS 

Risk  analysis  takes  the  information  at  hand  and  compares  it  to  previously  defined 
criteria  to  determine  the  potential  impact  and  likelihood  of  that  event  occurring.  In  the 
RTP  cost  and  schedule  data  and  statistics  were  derived  from  simulations  with  models. 
The  risks  to  schedule  are  centered  on  the  impact  and  likelihood  of  exceeding  78  weeks 
(18  months).  The  increased  performance  risks  associated  with  each  task’s  timeline 
reduction  strategies  are  direct  SME  opinions  on  the  nature  of  the  increased  impact,  and 
the  increased  likelihood  of  it  occurring  given  that  the  given  strategy  was  implemented. 
The  Baseline  cases  were  assumed  to  have  no  additional  performance  risk. 

B.  SCHEDULE  AND  PERFORMANCE  RISK 

The  statistical  results  from  running  the  schedule  model  simulation  500  times  were 
used  to  calculate  the  maximum  number  of  weeks  the  schedule  might  exceed  78  weeks 
and  the  likelihood  of  exceeding  that  threshold  for  each  of  the  27  scenarios.  Once 
calculated,  the  values  were  entered  into  summary  tables,  with  one  table  for  each  DRM 
base  scenario.  Both  the  calculations  and  the  summary  tables  can  be  found  in  Appendix  G. 
The  schedule  risk  ratings  were  determined  by  comparing  the  percent  likelihood  against 
the  rating  value  definitions  in  Table  5  and  the  impact  values  against  the  impact  rating 
value  definitions  in  Table  6.  For  each  scenario  and  run  the  corresponding  risk  ratings 
were  then  used  to  mark  the  risk  cube  (Table  7)  with  the  initials  for  the  risk  type  and  run 
number;  i.e.,  SI  stands  for  Schedule  risk  for  run  1. 
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What  is  the  likelihood  the  risk  will  happen? 

Level 

Likelihood 

Probability  of  Occurrence 

i 

Not  Likely 

— 10%...will  effectively  avoid  or  mitigate 
this  risk  based  on  standard  practices. 

2 

Low 

Likelihood 

—30%  ...have  usually  mitigated  this  type 
of  risk  with  minimal  oversight  in  similar 
cases. 

3 

Likely 

—50%  ...may  mitigate  this  risk,  but 
workarounds  will  be  required. 

4 

Highly 

Likely 

—70%.. . cannot  mitigate  this  risk,  new 
approach  and/or  workaround  will  be 
required. 

5 

Near 

Certainty 

-90%.. . cannot  mitigate  this  risk,  no  known 
processes  or  workarounds  are  available. 

Table  5:  Risk  Likelihood  Definitions 


Given  the  risk  is  realized,  what  would  be  the  magnitude  of  the  impact. 

Level 

Performance 

Schedule 

i 

Minimal  or  no  consequence  to  performance. 

Minimal  or  no  impact 

2 

Minor  reduction  in  performance  or 
supportability  can  be  tolerate  with  little  or  no 
impact  on  program,  same  approach  retained. 

Additional  resources  required,  able  to 
meet  key  dates. 

Slip  <  2  months 

3 

Moderate  reduction  in  performance  or 
supportability  with  limited  impact  on 
program  objectives,  workarounds  available. 

Minor  schedule  slip,  no  impact  to  key 
milestones. 

Slip  <  4  months 

4 

Significant  degradation  in  performance  or 
major  shortfall  in  supportability,  may 
jeopardize  program  success;  workarounds 
may  not  be  available  or  may  have  negative 
consequences. 

Program  critical  path  affected,  all 
schedule  float  associated  with  key 
milestone  exhausted. 

Slip  <  6  months 

5 

Severe  degradation  m  performance:  cannot 
meet  KPP  or  key  technical/ supportability 
threshold;  will  jeopardize  program  success; 
no  workarounds  available. 

Cannot  meet  key  program  milestones. 

Slip  >  6  months 

nr*  +  nn  T"%  ■  h  t  t-s.  r®-  th.  h  r-i  h  h 


Table  6:  Risk  Impact  Definitions  for  Performance  and  Schedule 
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System  Nil  me 

L 

i 

k 

e 

1 

i 

h 

0 

0 

d 

Performance  /  Schedul 

e 

5 

4 

3 

2 

1 

1 

2 

3 

4 

5 

Consequence 

Table  7:  Generic  Risk  Cube  Diagram 


Similarly,  the  statistical  results  from  10,000  simulation  runs  with  the  cost  model 
were  used  to  determine  the  maximum  amount,  in  $K,  that  the  cost  might  exceed  the  mean 
and  the  likelihood  of  doing  so  for  each  of  the  27  scenarios.  The  mean  was  used  for  cost 
because  that  was  the  most  common  amount  used  for  budgeting.  These  values  were  then 
entered  in  the  same  summary  table  with  schedule  values,  found  in  Appendix  G. 

Performance  risk  estimates  were  determined  based  on  timeline  reduction  options, 
performance  risk  value  definitions  in  Table  6,  and  likelihood  value  definitions  in  Table  5. 
Once  determined,  the  risk  rating  values  were  recorded  directly  in  the  risk  rating  tables. 

C.  RISK  ANALYSIS  SUMMARY 

The  values  in  the  risk  rating  tables  (Table  8,  Table  9,  and  Table  10)  were  used  to 
mark  the  risk  level  in  the  corresponding  risk  cubes  (Figure  32,  Figure  33,  and  Figure  34). 
The  risk  analysis  took  the  statistical  data  derived  from  simulation  with  the  models  for  the 
various  DRM  run  cases  and  information  elicited  from  the  PMA-263  SMEs  and  compared 
them  to  the  risk  definitions  in  Tables  5  and  6  to  determine  risk  ratings.  Schedule  Risk 
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ratings  were  determined  for  the  Baseline  (full  certifications)  and  both  timeline  reduction 
strategies.  Added  performance  risk  ratings  were  only  determined  for  the  timeline 
reduction  strategies. 

As  expected,  the  IRTR  and  LRTR  strategies  applied  to  mature  payloads  had  the 
lowest  schedule  risks  because  of  the  liberal  use  of  interim  approvals  and  pre-certified 
components.  For  each  payload  type,  the  Simple  Integration  Baseline  had  the  highest 
schedule  risks  because  all  applicable  certifications  had  to  be  pursued  for  full  approval. 
This  can  be  mitigated  through  early  implementation  of  the  RTP  checklist  (Appendix  H) 
and  tailor-able  schedule  (Appendix  I)  to  identify  which  certifications  and  their  associated 
data  requirements  are  needed. 

No  performance  risks  were  assessed  against  the  Baseline  strategy  because 
thorough  analysis  was  expected  during  the  pursuit  of  full  certification.  The  LRTR  option 
offered  the  lowest  performance  risks  because  previously  certified  components  would 
have  had  sufficient  analysis/testing  prior  to  authorization.  The  IRTR  strategy  had 
moderate  performance  risks  because  interim  approvals  are  granted  due  to  operational 
needs  and  limited  data  availability,  resulting  in  potentially  unknown  hazards.  To  mitigate 
this  risk  level,  early  identification  of  the  required  data  and  testing  should  be  provided  to 
the  technology  developer  to  support  a  more  comprehensive  certification  request  package. 
In  this  situation,  an  interim  approval  would  only  be  necessary  to  provide  the  certification 
authority  time  to  generate  the  formal  authorization. 
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Use  Case 

Laser  Designator 

Performance 

Schedule 

Scenario  1 

Baseline- Full  Certification 

Likelihood 

Consequence 

Likelihood 

Consequence 

1 

Simple  Integration 

N/A 

N/A 

4 

5 

2 

Complex  Integration 

N/A 

N/A 

4 

5 

3 

Highly  Mature  Payload  Integration 

N/A 

N/A 

1 

1 

Scenario  2 

Intermediate  Risk  Timeline  Redaction 
(IRTR) 

1 

Simple  Integration 

3 

3 

1 

2 

2 

Complex  Integration 

3 

3 

1 

2 

3 

Highly  Mature  Payload  Integration 

3 

3 

1 

i 

Scenario  3 

Low  Risk  Time  Reduction  [LRTR} 

1 

Simple  Integration 

2 

2 

1 

2 

2 

Complex  Integration 

2 

2 

1 

2 

3 

Highly  Mature  Payload  Integration 

2 

2 

1 

i 

Table  8:  LASER  Designator  Risk  Table 


LASER  Designator  IRTR 

L 

i 

k 

e 

1 

i 

h 

0 

o 

d 

Performance  /  Schedule 

5 

4 

3 

PI  ¥2 
P3 

2 

1 

S3 

SI  S2 

1 

2 

3 

4 

5 

Consequence 

LASER  Designator  BL 

L 

i 

k 

e 

1 

i 

h 

0 

0 

d 

Performance  /  Schedule 

5 

4 

3 

2 

I 

S3 

1 

2 

3 

4 

5 

Consequence 

LASER  Designator  LRTR 

L 

i 

k 

e 

1 

i 

h 

0 

0 

d 

Performance  f  Schedule 

5 

4 

3 

2 

pi  pi 

P3 

1 

S3 

SI  S2 

1 

2 

3 

4 

5 

Consequence 

Figure  32:  LASER  Designator  Risk  Cubes 
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Use  Case 

Passive  EW 

Performance 

Schedule 

Scenario  1 

Base  line- Full  Certification 

Likelihood 

Consequence 

Likelihood 

Consequence 

1 

Simple  Integration 

N/A 

N/A 

5 

5 

2 

Complex  Integration 

N/A 

N/A 

4 

5 

3 

Highly  Mature  Payload  Integration 

N/A 

N/A 

1 

1 

Scenario  2 

Intermediate  Risk  Timeline  Reduction 
(IRTR) 

1 

Simple  Integration 

3 

3 

5 

5 

2 

Complex  Integration 

3 

3 

1 

2 

3 

Highly  Mature  Payload  Integration 

3 

3 

1 

1 

Scenario  3 

Low  Risk  Time  Reduction  (LRTRJ 

1 

Simple  Integration 

2 

2 

3 

5 

2 

Complex  Integration 

2 

2 

1 

2 

3 

Highly  Mature  Payload  Integration 

2 

2 

1 

1 

Table  9:  Passive  EW  Risk  Table 


Passive  EW  BL 

L 

i 

k 

e 

1 

i 

h 

0 

0 

d 

Performance  /  Schedule 

5 

4 

3 

2 

1 

S3 

1 

2 

3 

4 

5 

Consequence 

Passive  EW  IRTR 

L 

i 

k 

e 

1 

i 

b 

O 

0 

d 

Performance  /  Schedule 

5 
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Figure  33:  Passive  EW  Risk  Cubes 
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Use  Case 

Active  EW 

Performance 

Schedule 

Scenario  1 

Base  line- Full  Certifi cation 

Likelihood 

Consequence 

Likelihood 

Consequence 

1 

Simple  Integration 

N/A 

N/A 

5 

5 

2 

Complex  Integration 

N/A 

N/A 

5 

5 

3 

Highly  Mature  Payload  Integration 

N/A 

N/A 

5 

5 

Scenario  2 

Intermediate  Risk  Timeline  Reduction 
(IFtTR) 

1 

Simple  Integration 

3 

3 

5 

5 

2 

Complex  Integration 

3 

3 

1 

2 

3 

Highly  Mature  Payload  Integration 

3 

3 

1 

1 

Scenario  3 

Low  Risk  Time  Reduction  [LRTR} 

1 

Simple  Integration 

2 

2 

3 

5 

2 

Complex  Integration 

2 

2 

1 

2 

3 

Highly  Mature  Payload  Integration 

2 

2 

1 

1 

Table  10:  Active  EW  Risk  Tables 
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Figure  34:  Active  EW  Risk  Cubes 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

The  RAIN  Team  successfully  consolidated  individual  procedures  currently 
employed  independently  by  the  responsible  NAVAIR  competencies  into  the  systematic 
RTP  process  that  efficiently  satisfies  the  applicable  Statutory  and  Regulatory 
requirements  needed  to  successfully  integrate  a  new  capability  into  the  DoN  System. 
Having  a  process  enabled  the  use  of  modeling  and  simulation  and  through  the  modeling 
and  simulation  of  payload  types  most  commonly  installed  on  PMA-263  platforms,  the 
Team  determined  that  full  certification  of  the  modified  system  using  the  developed 
process  can  take  between  34  and  180  weeks.  This  schedule  also  depends  on  integration 
complexity  and  use  of  already-certified  components. 

In  addition  to  improved  efficiencies,  the  RTP  further  demonstrated  its 
effectiveness  by  meeting  the  project’s  MOE,  Probability  of  addressing  all  statutory  and 
regulatory  requirements  to  enable  fielding  of  a  new  payload  to  the  warfighter  in  18 
months.  The  Team  identified  the  certifications  that  caused  elongation  of  the  fielding 
timeline  and  examined  alternative  options  that  would  also  satisfy  the  project’s  MOPs. 
MOP  1,  Number  of  interim  technical  certifications,  was  achieved  by  using  components 
that  already  had  some  of  the  required  certifications.  MOP  2,  Median  time  to  gain 
approval  to  field  a  new  capability,  was  achieved  by  a  reduction  in  the  timeline  through 
interim  certifications,  as  described  in  the  IRTR  and  LRTR  strategies,  resulting  in 
integration  within  14  to  92  weeks.  Because  a  sufficient  decrease  in  the  schedule  was 
obtained  through  interim  approvals,  the  effects  and  risks  of  waivers  from  the  applicable 
certifications  were  determined  to  be  unnecessary,  and  therefore  not  incorporated  into  the 
timeline  reduction  strategies. 

B.  TIMELINE  REDUCTION  OPTIONS 

The  RTP,  through  use  of  the  Payload  Integration  Checklist  (Appendix  H)  and  the 

Payload  Integration  Schedule  (Appendix  I),  can  achieve  comprehensive  integration  of  a 
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new  capability.  But  some  certifications  could  delay  fielding  due  to  the  workload  and 

extensive  reviews  conducted  by  external  agencies.  The  Team  identified  the  following 

applicable  options  (along  with  associated  risks)  to  expedite  the  certification  process: 

Spectrum 

Options 

1)  Operate  on  a  temporary  frequency  assignment.  If  a  system  operates  on  an 
“interim”  stage  three  (3)  frequency  authorization,  they  can  request  local  spectrum 
on  a  “not-to-interfere”  basis.  The  stage  3  SPS  submittal  number  will  allow  the 
user  to  obtain  authorization  to  operate.  It  takes  one  (1)  to  two  (2)  months  to  get  an 
SPS  number;  and  one  (1)  to  two  (2)  months  to  get  local  spectrum  allocation. 

2)  Limit  payload  selection  to  those  that  already  have  an  SPS  number  or  full  spectrum 
authorization  (J/F  12).  Only  a  frequency  allocation  needs  to  be  obtained  and  the 
time  frame  will  shorten  to  one  (1)  to  two  (2)  months. 

Risk 

1)  Temporary  frequency  assignment.  A  “not-to-interfere”  basis  may  limit  the 
system’s  operational  availability,  and  thus,  usefulness  to  the  user. 

2)  Limit  payload  selection.  This  may  limit  capabilities  and  cause  potential 
integration  issues.  It  may  also  reduce  competition  and  increase  system  cost. 

CDL 

Options 

1 .  Limit  payload  selection  to  payloads  that  already  have  a  CDL  or  use  the  existing 
communications  architecture  in  the  target  platform.  This  automatically  addresses 
the  CDL  requirement  and  time  goes  to  zero  (0). 

Risk 

1)  This  may  limit  capabilities  and  cause  potential  integration  issues.  It  may  also 
reduce  competition  and  increase  system  cost. 

GPS 

Options 
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1)  Limit  payload  selection  to  payloads  that  already  have  a  SAASM  GPS  or  use  the 
existing  navigation  architecture  in  the  target  platform.  This  automatically 
addresses  the  SAASM  GPS  requirement  and  time  goes  to  zero  (0). 

Risk 

1)  This  may  limit  capabilities  and  cause  potential  integration  issues.  It  may  also 
reduce  competition  and  increase  system  cost. 

T  and  E 

Options 

1)  Conduct  joint  DT/OT.  This  will  eliminate  the  lead-time  between  DT  and  OT.  The 
OT  testing  time  goes  to  zero  (0) 

2)  Conduct  OT  during  a  preliminary  system  fielding.  Have  users  evaluate  the  system 
during  operations.  This  will  eliminate  the  OT  lead  time  and  testing  time. 

Risk 

1)  Joint  DT  /  OT.  The  time  to  address  any  problems  typically  discovered  in  DT  is 
removed.  If  an  issue  arises,  it  cannot  be  fixed  before  OT. 

2)  Preliminary  fielding  OT.  A  problem  may  be  discovered  in  the  field  or  while  on 
mission.  Depending  on  the  severity  of  the  issue,  the  system  may  be  useless  or 
engineers  may  have  to  be  sent  into  theater  to  investigate  and  fix  the  issue  on  site. 

JITC 

Options 

1)  Obtain  a  limited  JITC  while  conducting  Tand  E  and  training  activities  to  support 
preliminary  fielding.  Full  JITC  certification  is  required  for  Initial  Operational 
Capability  (IOC),  but  not  necessary  for  preliminary  fielding.  This  will  reduce  the 
timeline  to  zero  for  JITC  in  the  fielding  path,  allowing  it  to  run  parallel  but 
independent  of  the  rest  of  the  certification  work. 

Risk 

1)  Operating  without  JITC  certification  limits  the  operation  of  the  equipment.  The 
system  may  not  be  allowed  to  connect  to  certain  systems,  and  interoperability 
with  other  systems  cannot  be  assured. 
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Information  Assurance 

Options 

1)  Obtain  an  Interim  Authority  To  Operate  (IATO).  This  is  a  temporary 
authorization  to  operate  a  system  under  the  conditions  or  constraints  enumerated 
in  the  accreditation  decision  while  managing  IA  security  weaknesses.  An  IATO  is 
only  good  for  180  days  from  the  authorization  date  and  can  be  obtained  within  30 
days. 

Risk 

1)  The  system  may  have  insufficient  security  protection  and  may  be  susceptible  to 
compromise  by  an  unauthorized  user. 

Battery 

Options 

1)  Limit  payload  selection  to  payloads  that  already  have  a  NOSSA  approval.  This 

automatically  addresses  the  battery  certification  and  time  goes  to  zero  (0). 

2)  Obtain  an  interim  approval  to  operate  the  subject  battery  for  a  limited  amount  of 

time.  This  will  authorize  fielding  of  the  payload  while  NOSSA  conducts  its 
testing/analysis  in  parallel. 

Risk 

1)  Limited  payload  selection.  This  may  limit  capabilities  and  cause  potential 
integration  issues.  It  may  also  reduce  competition  and  increase  system  cost. 

2)  Interim  approval.  The  battery  may  be  utilized  in  a  manner  that  could  be  harmful 
to  personnel  and  equipment  within  its  vicinity.  The  battery  may  fail  certification 
and  have  to  be  retrofitted  in  the  field.  There  is  also  the  possibility  of  decreased 
availability  and  increased  maintenance  due  to  battery  failures  in  the  field,  driving 
up  life  cycle  cost. 

Airworthiness 

Options 

1)  Obtain  a  Cat  III  interim  flight  clearance  (IFC).  This  reduces  the  amount  of  data 
needed  prior  to  issuing  an  airworthiness  certification  and  can  be  released  within 
30  days. 
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Risk 

1)  Without  sufficient  data/documentation,  an  IFC  can  be  released  with  very  stringent 
limitations  and  restrictions,  creating  a  relatively  small  envelope  in  which  the 
system  can  be  operated.  This  would  limit  the  warfighter’s  ability  to  complete  the 
mission.  Expanding  the  operating  envelope  without  sufficient  testing  could  result 
in  injury  to  personnel  or  loss  of  life/property. 

C.  RECOMMENDATIONS 

The  trade  study  looked  for  ways  to  optimize  and  balance  the  three  (3)  pillars  of 
SE,  maintain  SE  discipline,  and  meet  rapid  integration  timelines.  The  RAIN  Team 
recommends  the  IRTR  strategy  as  the  best  option  to  meet  a  rapid  fielding  decision 
timeline.  Three  (3)  integration  strategies  were  analyzed  based  on  the  timeline  reduction 
options  outlined  in  Section  B  above.  The  first  strategy,  Baseline,  focused  on  a  purely 
technical  solution  and  pursued  full  certifications  for  all  applicable  requirements.  The 
second  strategy,  LRTR,  focused  on  an  optimal  schedule  with  the  shortest  timeline 
possible.  The  third  strategy,  IRTR,  looked  at  applying  balance  of  the  systems  engineering 
pillars.  Each  strategy  was  summarized  for  all  of  the  scenario  combinations  in  Figure  35. 
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Figure  35:  (Risk)  Schedule  Summary  Results 

The  Baseline  option  was  rejected  based  on  its  inability  to  meet  a  feilding  decision 
timeline  of  18  months  despite  offering  the  least  ammount  of  technical  risk.  The  LRTR 
option  was  identified  as  a  suitable  option  to  meet  timelines  while  minimizing  technical 
risk;  however,  it  was  also  rejected  as  the  optimal  solution  because  it  overly  sacrificed 
technical  capability  through  the  inflexible  payload  options  for  schedule  optimizations. 
But  in  extremely  compressed  situations,  the  LRTR  strategy  may  be  a  viable,  yet 
restrictive  option. 

The  IRTR  stratagy  was  determined  to  be  the  optimal  SE  approach  because  it 
balanced  the  three  (3)  pillars  of  SE  and  supported  a  fielding  decision  timeline  inside  1 8 
months  in  a  majority  (7  or  9)  of  the  scenarios.  This  stratagy  significantly  reduced  the 
average  cost  and  schedule  to  integrate  and  field  a  new  payload,  while  still  managing 
technical  risk.  While  this  strategy  does  not  provide  the  fastest  option,  it  does  provide  a 
suitable  fielding  timeline  for  reasonable  cost  and  acceptably  mitigating  technical  and 
operational  risk.  From  a  practical  aspect  this  is  also  the  most  realistic  scenairo. 
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D.  AREAS  OF  FUTURE  STUDY 


Although  the  scope  of  this  project  was  limited  to  modular  payloads  for  existing 
PMA-263  UAS  inventory,  the  applicability  of  the  RTP  can  be  expanded  further.  The  RTP 
can  be  implemented  on  the  certification  of  entire  platforms  and  payloads  that  require 
modification  of  the  current  system  configuration.  In  addition,  the  Team  identified  the 
following  areas  that  could  benefit  from  additional  investigation: 

•  Applicability  of  RTP  to  other  areas  of  NAVAIR.  This  could  be  applied  in  other 

PEOs  or  competencies,  where  technologies  need  to  be  fielded  rapidly  or  more 
efficiently  to  minimize  schedule  or  costs. 

•  Research  the  individual  certification  processes  to  identify  areas  for  efficiencies  in 

terms  of  cost  and  schedule.  Apply  the  RTP  to  each  of  the  certifications  for  better 
implementation. 

•  Update  the  model  and  simulation  to  provide  results  for  pursuing  waivers  instead 

of  full  or  interim  certifications. 

•  Build  a  tool  that  takes  the  users  responses  to  questions  about  the  system  and 

produces  an  ordered  list  of  certifications  to  complete,  and  an  80th  percentile  plan 
for  schedule  and  cost. 

•  The  same  process  can  be  expanded  to  include  logistical  support. 

•  Implementation  on  actual  payload  integration  efforts  needs  to  be  conducted  to 

validate  the  RTP. 
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APPENDIX  A.  MISSION  PROFILES 


Design  Reference  Missions 
Full  Certification 
Waiver  or  Interim  Certification 
Waiver  or  Interim  Certification  Denied 
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Design  Reference  Mission:  Interim  Certification 
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7a 
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Abandoned 


Initiate  RTP 


Requested 


SMEs 


9 

Risk 

Assessment 


5 

Data  for  > 

nalysis 

6 

Data  insi 

ITicient 

7b 

Request  Testing 

10 

enm  Package  : 
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Design  Reference  Mission:  Interim  Certification  Denied 


Warfighter 
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APPENDIX  B.  ARCHITECTURE  AND  DEVELOPMENT 


Number 

Name 

Description 

refines 

refined  by 

basis  of 

0 

REQUIREMENTS 

CONTEXT 

These  are  the  requirements  for  the  system 
architecture.  The  system  is  the  solution  under 
development  or  analysis.  This  will  cover  inside 
and  outside  the  system  boundary  (may  be  a 
System  of  Systems).  The  higher  level 
requirements  trace  back  to  the  capabilities. 
Requirements  are  decomposed  from  high  level 
solution-neutral  capabilities  and  requirements 
all  the  way  down  to  solution-oriented  system 
specifications. 

1  INPUT/OUTPUT 
REQUIREMENTS 

2  TECHNOLOGY  & 
SYSTEM-WIDE 
REQUIREMENTS 

3  TRADE-OFF 
REQUIREMENTS 

4  QUALIFICATION 
REQUIREMENTS 

0  STUAS  System 

1 

INPUT/OUTPUT 

REQUIREMENTS 

The  system  shall  input  and  output  all  data 
required  in  this  section  to  support  integration 
and  fielding  of  payloads  on  STUAS. 

0  REQUIREMENTS 
CONTEXT 

1.1  INPUT 

1.2  OUTPUT 

1.3  EXTERNAL 
INTERFACE 

1.4  FUNCTIONAL 
REQUIREMENTS 

1.1  Determine 
Certifications 

1.2  Collect  Certifications 

1 .3  Analyze  Certifications 

1 .4  Address  Risk 

1.5  Develop  Certification 
Package 

1.1 

INPUT 

The  system  shall  input  all  data  required  in  this 
sections  below  to  support  integration  and 
fielding  of  payloads  on  STUAS  at  the  Mission, 
Stakeholder,  System,  Component,  and 
Configuration  levels. 

1  INPUT/OUTPUT 
REQUIREMENTS 

1.1.1  Payload 

1.1.2  Technical  Data  Package 

1.1.3  Technical  Guidance 
from  Certification  Authority 

1.1.4  Payload  Returned  from 

Testing 

1.1.5  T&E  Results  Summary 

1.1.6  Packages  from 
Technical  Certification 

1.2.1  Assemble  Data  Item 

1.2.2  Perform  Authority 
Officer 

1.2.3  Perform  Data 
Collection 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

Authorities 

1.1.7  System  Requirements 

1.1.1 

Payload 

The  system  shall  input  all  payload  data. 

1.1  INPUT 

1  Perform  Rain  Integration 
Process 

1.1  Determine 
Certifications 

1.1.2 

Technical  Data 
Package 

The  system  shall  input  Technical  Data 
Packages  to  support  certification 

1.1  INPUT 

1 . 1 .2. 1  Design  Description 

1.1.2 .2  Payload  Data 

1.2.3  Perform  Data 
Collection 

1.2. 3.1  Collect  Safety 
Certification  Data 

1.2. 3. 2  Collect  Security 
Certification  Data 

1.2.3. 3  Collect 
Interoperability 

Certification  Data 

1.2.3. 4  Collect 
Compatibility  Certification 

Data 

1. 1.2.1 

Design  Description 

A  technical  description  of  the  payload  covering 
fit,  form,  function,  and  how  it  interfaces. 

1.1.2  Technical  Data 
Package 

1.1. 2. 1.1  System  Trigger 

1.2.3. 1.1  Collect 
Airworthiness 
Certifications  Data 

1.2. 3. 1.2  Collect  Battery 
Certifications  Data 

1.2. 3. 1.3  Collect  Laser 
Certifications  Data 

1.2. 3. 1.4  Collect  Weapon 
Certifications  Data 

1.2. 3. 1.5  Collect  System 
Safety  Certifications  Data 

1.2. 3. 1.6  Collect  Range 
Safety  Certification  Data 
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Number 


Name 


Description 


1. 1.2.1. 1 

System  Trigger 

The  system  shall  be  initiated  by  the  receipt  of  a 
first  article  and  design  description. 

1. 1.2.2 


Payload  Data 


The  data  about  the  payload  that  is  needed  for 
certification. 


refines 

refined  by 

basis  of 

1.2.3. 1.7  Collect  E3 
Certification  Data 

1.2.3. 2.1  Collect  IA 
Certifications  Data 

1.2. 3. 2. 2  Collect  Anti- 
Tamper  Certifications  Data 

1.2.3. 2.3  Collect  SAASM 
Certifications  Data 

1.2. 3. 2.4  Collect  Clinger- 
Cohen  Act  Certifications 

Data 

1.2. 3. 3.1  Collect  Spectrum 
Certifications  Data 

1.2.3.3.2  Collect  CDL 
Certifications  Data 

1.2.3.3.3  Collect  JITC 
Certifications  Data 

1. 2.3.4. 1  Collect 
Environmental 
Certifications  Data 

1.2. 3.4. 2  Collect  T&E 
Certifications  Data 

1.1. 2.1  Design 
Description 

1  Perform  Rain  Integration 
Process 

1.1.2  Technical  Data 
Package 

1 . 1 .2.2. 1  Data  for  Each  Type 
of  Certification 

1.2. 3.1  Collect  Safety 
Certification  Data 

1.2. 3. 2  Collect  Security 
Certification  Data 

1.2.3. 3  Collect 
Interoperability 
Certification  Data 


Number 

Name 

Description 

refines 

refined  by 

basis  of 

1.2.3. 4  Collect 
Compatibility  Certification 
Data 

1.1. 2.2.1 

Data  for  Each  Type 
of  Certification 

The  system  shall  support  inputting  all  data  for 
each  certification. 

1.1.2 .2  Payload  Data 

1.1. 2.2. 1.1  Data  for  Individual 
Certification 

1.2.3. 1.1  Collect 
Airworthiness 

Certifications  Data 

1.2. 3. 1.2  Collect  Battery 
Certifications  Data 

1.2. 3. 1.3  Collect  Laser 
Certifications  Data 

1.2. 3. 1.4  Collect  Weapon 
Certifications  Data 

1.2. 3. 1.5  Collect  System 
Safety  Certifications  Data 

1.2.3. 1.6  Collect  Range 
Safety  Certification  Data 

1.2.3. 1.7  Collect  E3 

Certification  Data 

1.2.3. 2.1  Collect  IA 

Certifications  Data 

1.2. 3. 2. 2  Collect  Anti- 
Tamper  Certifications  Data 

1.2.3. 2.3  Collect  SAASM 
Certifications  Data 

1.2. 3. 2.4  Collect  Clinger- 
Cohen  Act  Certifications 
Data 

1.2.3. 3.1  Collect  Spectrum 
Certifications  Data 

1.2.3. 3. 2  Collect  CDL 

Certifications  Data 

86 


Number 

Name 

Description 

refines 

refined  by 

basis  of 

1.2.3. 3. 3  Collect  JITC 

Certifications  Data 

1.2.3. 4.1  Collect 
Environmental 

Certifications  Data 

1.2.3. 4.2  Collect  T&E 

Certifications  Data 

1. 1.2.2. 1. 

1 

Data  for  Individual 
Certification 

The  system  shall  input  all  data  for  each 
certification  required  for  specific  payload 
integration  and  fielding  as  identified  by  the 
certification  authority. 

1.1. 2.2.1  Data  for 
Each  Type  of 

Certification 

1.2.3. 1.1  Collect 
Airworthiness 

Certifications  Data 

1.2. 3. 1.2  Collect  Battery 
Certifications  Data 

1.2. 3. 1.3  Collect  Laser 

Certifications  Data 

1.2.3. 1.4  Collect  Weapon 
Certifications  Data 

1.2. 3. 1.5  Collect  System 
Safety  Certifications  Data 

1.2. 3. 1.6  Collect  Range 

Safety  Certification  Data 

1.2.3. 1.7  Collect  E3 

Certification  Data 

1.2.3. 2.1  Collect  IA 

Certifications  Data 

1.2. 3. 2. 2  Collect  Anti- 

Tamper  Certifications  Data 

1.2.3. 2.3  Collect  SAASM 
Certifications  Data 

1.2. 3.2.4  Collect  Clinger- 
Cohen  Act  Certifications 
Data 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

1.2. 3. 3.1  Collect  Spectrum 
Certifications  Data 

1.2.3. 3. 2  Collect  CDL 

Certifications  Data 

1.2.3. 3. 3  Collect  JITC 

Certifications  Data 

1.2.3. 4.1  Collect 
Environmental 

Certifications  Data 

1.2.3. 4.2  Collect  T&E 

Certifications  Data 

1.1.3 

Technical  Guidance 
from  Certification 
Authority 

The  system  shall  input  data  from  each  technical 
certification  authority  to  identify  payload 
specific  data  and  certification  applicability. 

1.1  INPUT 

1.1.1  Construct 
Certification  List 

1.1.2  Assemble 
Certification  Components 

1.1. 2.1  Determine  Safety 
Certifications 

1.1. 2. 1.1  Address 
Airworthiness 

Certifications 

1.1. 2. 1.2  Address  Battery 
Certifications 

1.1. 2. 1.3  Address  Laser 
Certifications 

1.1. 2. 1.4  Address  Weapon 
Certifications 

1.1. 2. 1.5  Address  System 
Safety  Certifications 

1.1. 2. 1.6  Address  Range 
Safety  Certifications 

1.1. 2. 1.7  Address  E3 
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refined  by 


basis  of 


Certifications 

1.1. 2.2  Determine  Security 
Certifications 

1.1. 2.2.1  Address  IA 
Certifications 

1.1. 2.2. 2  Address  Anti- 
Tamper  Certifications 

1.1. 2.2.3  Address  SAASM 
Certifications 

1.1. 2. 2. 4  Address  Clinger- 
Cohen  Act  Certifications 

1.1. 2.3  Determine 

Interoperability 

Certifications 

1.1. 2.3.1  Address 
Spectrum  Certifications 

1.1. 2.3. 2  Address  CDL 

Certifications 

1.1. 2.3. 3  Address  JITC 

Certifications 

1.1. 2. 4  Determine 

Compatibility 

Certifications 

1.1. 2.4.1  Address 
Environmental 
Certifications 

1.1. 2.4.2  Address  T&E 

Certifications 

1.3  Analyze  Certifications 
1.3.1  Specify  Data 


Number 

Name 

Description 

refines 

refined  by 

basis  of 

1.3.2  Provide  Analysis 

1.3. 2.1  Analyze  Safety 
Certification  Data 

1.3. 2. 1.1  Analyze 
Airworthiness 

Certifications  Data 

1 . 3 . 2 . 1 . 2  Analyze  B  attery 
Certifications  Data 

1.3. 2. 1.3  Analyze  Laser 
Certifications  Data 

1.3. 2. 1.4  Analyze  Weapon 
Certifications  Data 

1.3. 2. 1.5  Analyze  System 
Safety  Certifications  Data 

1.3. 2. 1.6  Analyze  Range 
Safety  Certifications  Data 

1.3. 2. 1.7  Analyze  E3 
Certification  Data 

1. 3.2.2  Analyze  Security 
Certifications  Data 

1.3. 2. 2.1  Analyze  I A 
Certifications  Data 

1.3. 2. 2. 2  Analyze  Anti- 
Tamper  Certifications  Data 

1.3. 2.2.3  Analyze  SAASM 
Certifications  Data 

1.3.2.2.4  Analyze  Clinger- 
Cohen  Act  Certifications 
Data 

1.3. 2. 3  Analyze 

Interoperability 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

Certifications  Data 

1.3. 2. 3.1  Analyze 

Spectrum  Certifications 

Data 

1.3. 2. 3. 2  Analyze  CDL 
Certifications  Data 

1.3. 2.3. 3  Analyze  JITC 
Certifications  Data 

1.3. 2. 4  Analyze 

Compatibility  Certification 
Data 

1.3. 2.4.1  Analyze 
Environmental 

Certifications  Data 

1.3. 2.4.2  Analyze  T&E 
Certifications  Data 

1.1.4 

Payload  Returned 
from  Testing 

The  system  shall  input  technical  data  captured 
during  all  testing 

LI  INPUT 

1.3.2  Provide  Analysis 

1.3. 2.1  Analyze  Safety 
Certification  Data 

1.3. 2. 1.1  Analyze 
Airworthiness 

Certifications  Data 

1 . 3 . 2 . 1 . 2  Analyze  B  attery 
Certifications  Data 

1.3. 2. 1.3  Analyze  Laser 
Certifications  Data 

1.3. 2. 1.4  Analyze  Weapon 
Certifications  Data 

1.3. 2. 1.5  Analyze  System 
Safety  Certifications  Data 

1.3. 2. 1.6  Analyze  Range 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

Safety  Certifications  Data 

1.3. 2. 1.7  Analyze  E3 
Certification  Data 

1. 3.2.2  Analyze  Security 
Certifications  Data 

1.3. 2.2.1  Analyze  IA 
Certifications  Data 

1.3. 2. 2. 2  Analyze  Anti- 
Tamper  Certifications  Data 

1.3. 2.2.3  Analyze  SAASM 
Certifications  Data 

1.3.2.2.4  Analyze  Clinger- 
Cohen  Act  Certifications 
Data 

1.3. 2. 3  Analyze 

Interoperability 
Certifications  Data 

1.3. 2. 3.1  Analyze 

Spectrum  Certifications 

Data 

1.3. 2.3. 2  Analyze  CDL 

Certifications  Data 

1.3. 2.3. 3  Analyze  JITC 

Certifications  Data 

1.3. 2. 4  Analyze 

Compatibility  Certification 
Data 

1.3. 2.4.1  Analyze 
Environmental 

Certifications  Data 

1.3. 2.4. 2  Analyze  T&E 

Certifications  Data 

92 


Number 
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refined  by 

basis  of 

1.3.3  Address  Data 

Distribution 

1.1.5 

T&E  Results 

Summary 

The  summary  of  the  test  and  evaluation  results. 

1.1  INPUT 

1.1. 5.1  Collection  of  Test 

Reports 

1.3  Analyze  Certifications 

1. 1.5.1 

Collection  of  Test 
Reports 

The  collection  of  all  test  reports. 

1.1.5  T&E  Results 
Summary 

1.1. 5. 1.1  Test  Reports  for 
Each  Area 

1.3.1  Specify  Data 

1.3.2  Provide  Analysis 

1.3.3  Address  Data 

Distribution 

1.1.5. 1.1 

Test  Reports  for 
Each  Area 

The  system  shall  support  inputting  all  test 
reports  for  each  certification. 

1.1. 5.1  Collection  of 
Test  Reports 

1.1. 5. 1.1.1  Test  Reports  for 
Each  Certification  (as 

applicable) 

1.3. 2.1  Analyze  Safety 
Certification  Data 

1.3. 2.2  Analyze  Security 
Certifications  Data 

1.3. 2. 3  Analyze 
Interoperability 
Certifications  Data 

1.3. 2. 4  Analyze 
Compatibility  Certification 
Data 

1. 1.5.1. 1. 

1 

Test  Reports  for 
Each  Certification 
(as  applicable) 

The  system  shall  input  all  test  reports  for  each 
certification  required  for  specific  payload 
integration  and  fielding  as  identified  by  the 
certification  authority. 

1.1.5. 1.1  Test 

Reports  for  Each 
Area 

1.3. 2. 1.1  Analyze 
Airworthiness 

Certifications  Data 

1.3. 2. 1.2  Analyze  Battery 
Certifications  Data 

1.3. 2. 1.3  Analyze  Laser 
Certifications  Data 

1.3. 2. 1.4  Analyze  Weapon 
Certifications  Data 

1.3. 2. 1.5  Analyze  System 
Safety  Certifications  Data 

1.3. 2. 1.6  Analyze  Range 
Safety  Certifications  Data 
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Description 

refines 

refined  by 

basis  of 

1.3. 2. 1.7  Analyze  E3 
Certification  Data 

1.3. 2. 2.1  Analyze  I A 
Certifications  Data 

1.3. 2. 2. 2  Analyze  Anti- 
Tamper  Certifications  Data 

1.3. 2.2.3  Analyze  SAASM 
Certifications  Data 

1.3. 2. 2. 4  Analyze  Clinger- 
Cohen  Act  Certifications 
Data 

1.3. 2. 3.1  Analyze 

Spectrum  Certifications 

Data 

1.3. 2.3. 2  Analyze  CDL 
Certifications  Data 

1.3. 2.3. 3  Analyze  JITC 
Certifications  Data 

1.3. 2.4.1  Analyze 
Environmental 

Certifications  Data 

1.3. 2.4. 2  Analyze  T&E 
Certifications  Data 

1.1.6 

Packages  from 

Technical 
Certification 
Authorities 

The  complete  set  of  results  from  the  technical 
certification  authorities  for  all  sought 
certifications  along  with  a  summary  of  the 
results. 

1.1  INPUT 

1.1. 6.1  Collection  of 

Certification  Results 

1.3  Analyze  Certifications 

1.1 .6.1 

Collection  of 

Certification 

Results 

The  system  shall  input  the  results  of  each 
certification  request. 

1.1.6  Packages  from 
Technical 

Certification 

Authorities 

1.1. 6. 1.1  Certification  Results 
for  Each  Area 

1.3.1  Specify  Data 

1.3.2  Provide  Analysis 

1.3.3  Address  Data 

Distribution 
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Name 

Description 

refines 

refined  by 

basis  of 

1. 1.6.1. 1 

Certification 

Results  for  Each 
Area 

The  system  shall  input  overall  Safety,  Security, 
Interoperability,  and  Compatibility. 

1.1. 6.1  Collection  of 
Certification  Results 

1.1. 6. 1.1.1  Certification 

Results  for  Each  Type 

1. 3.2.1  Analyze  Safety 
Certification  Data 

1. 3.2.2  Analyze  Security 
Certifications  Data 

1.3. 2. 3  Analyze 
Interoperability 
Certifications  Data 

1.3. 2. 4  Analyze 
Compatibility  Certification 
Data 

1. 1.6.1. 1. 

1 

Certification 

Results  for  Each 
Type 

The  system  shall  input  all  certification  results 
for  each  certification  required  for  specific 
payload  integration  and  fielding  as  identified  by 
the  certification  authority. 

1. 1.6.1. 1 

Certification  Results 
for  Each  Area 

1.1.6. 1.1. 1.1  Individual 

Certification  Result 

1.3. 2. 1.1  Analyze 
Airworthiness 

Certifications  Data 

1 . 3 . 2 . 1 . 2  Analyze  B  attery 
Certifications  Data 

1.3. 2. 1.3  Analyze  Laser 
Certifications  Data 

1.3. 2. 1.4  Analyze  Weapon 
Certifications  Data 

1.3. 2. 1.5  Analyze  System 
Safety  Certifications  Data 

1.3. 2. 1.6  Analyze  Range 
Safety  Certifications  Data 

1.3. 2. 1.7  Analyze  E3 
Certification  Data 

1.3. 2.2.1  Analyze  IA 
Certifications  Data 

1.3. 2. 2. 2  Analyze  Anti- 
Tamper  Certifications  Data 

1.3. 2.2.3  Analyze  SAASM 
Certifications  Data 
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Name 

Description 

refines 

refined  by 

basis  of 

1.3.2.2.4  Analyze  Clinger- 
Cohen  Act  Certifications 
Data 

1.3. 2. 3.1  Analyze 

Spectrum  Certifications 

Data 

1.3. 2.3. 2  Analyze  CDL 
Certifications  Data 

1.3. 2.3. 3  Analyze  JITC 
Certifications  Data 

1.3. 2.4.1  Analyze 
Environmental 

Certifications  Data 

1.3. 2.4. 2  Analyze  T&E 
Certifications  Data 

1. 1.6.1. 1. 
LI 

Individual 
Certification  Result 

The  results  from  an  individual  certification 
effort  and  request. 

1. 1.6.1. 1.1 

Certification  Results 
for  Each  Type 

1.3. 2. 1.1  Analyze 
Airworthiness 

Certifications  Data 

1.3. 2. 1.2  Analyze  Battery 
Certifications  Data 

1.3. 2. 1.3  Analyze  Laser 
Certifications  Data 

1.3. 2. 1.4  Analyze  Weapon 
Certifications  Data 

1.3. 2. 1.5  Analyze  System 
Safety  Certifications  Data 

1.3. 2. 1.6  Analyze  Range 
Safety  Certifications  Data 

1.3. 2. 1.7  Analyze  E3 
Certification  Data 

1.3. 2. 2.1  Analyze  I A 
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Name 

Description 

refines 

refined  by 

basis  of 

Certifications  Data 

1.3. 2. 2. 2  Analyze  Anti- 
Tamper  Certifications  Data 

1.3. 2.2.3  Analyze  SAASM 
Certifications  Data 

1.3.2.2.4  Analyze  Clinger- 
Cohen  Act  Certifications 
Data 

1.3. 2. 3.1  Analyze 

Spectrum  Certifications 

Data 

1.3. 2. 3. 2  Analyze  CDL 
Certifications  Data 

1.3. 2.3. 3  Analyze  JITC 
Certifications  Data 

1.3. 2.4.1  Analyze 
Environmental 

Certifications  Data 

1.3. 2.4.2  Analyze  T&E 
Certifications  Data 

1.1.7 

System 

Requirements 

The  system  shall  input  the  payload  mission 
requirements. 

1.1  INPUT 

1 . 1  Determine 
Certifications 

1.2  Collect  Certifications 

1.3  Analyze  Certifications 

1 .4  Address  Risk 

1.5  Develop  Certification 
Package 

1.2 

OUTPUT 

The  system  shall  output  all  data  required  in  this 
sections  below  to  support  integration  and 
fielding  of  payloads  on  STUAS  at  the  Mission, 
Stakeholder,  System,  Component,  and 

1  INPUT/OUTPUT 
REQUIREMENTS 

1.2.1  Fielding  Decision 
Support  Package 

1.2.2  T&E  Supplies 

1 .4  Address  Risk 

1.5  Develop  Certification 
Package 
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Configuration  levels. 

1.2.3  Design  Guidance  to 
Developer 

1.2.4  Request  for  More  Data 
to  Developer 

1.2.5  Certification  Approval 
Request 

1.2.6  Packages  for 

Certification  (Initial  & 

Update) 

1.2.7  Risk  Assessment 

1.2.1 

Fielding  Decision 
Support  Package 

Documentation  that  shows  that  the  payload 
works  as  intended;  lists  all  required 
certifications;  shows  that  the  listed 

certifications  and  approvals  have  been  granted 
in  full,  or  as  interims,  or  have  been  waived  by 
suitable  authority.  This  is  composed  of  an 
overarching  summary  with  details  attached  as 
appendices. 

1.2  OUTPUT 

1 .4  Address  Risk 

1.5  Develop  Certification 
Package 

1.2.2 

T&E  Supplies 

Materials  and  labor  that  RAIN  needs  to  supply 
to  the  T&E  facilities  and  organizations. 

1.2  OUTPUT 

1. 2.2.1  T&E  Support  Request 

1.3  Analyze  Certifications 

1.2. 2.1 

T&E  Support 

Request 

The  system  shall  output  a  T&E  support  request. 

1.2.2  T&E  Supplies 

1.2.2. 1.1  Payload  to  T&E 

1.3.2  Provide  Analysis 

1.2.2. 1.1 

Payload  to  T&E 

The  system  shall  provide  an  integrated  payload, 
with  necessary  certifications  to  support  testing. 

1. 2.2.1  T&E  Support 
Request 

1 .2.2. 1 . 1 . 1  Direction  to  T&E 

1. 3.2.1  Analyze  Safety 
Certification  Data 

1. 3.2.2  Analyze  Security 
Certifications  Data 

1.3. 2. 3  Analyze 
Interoperability 
Certifications  Data 

1.3. 2. 4  Analyze 
Compatibility  Certification 
Data 
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Name 

Description 

refines 

refined  by 

basis  of 

1.2.2. 1.1. 

1 

Direction  to  T&E 

The  system  shall  output  the  needed  testing  data 
to  develop  test  plans. 

1.2.2. 1.1  Payload  to 
T&E 

1.3. 2. 1.1  Analyze 
Airworthiness 

Certifications  Data 

1 . 3 . 2 . 1 . 2  Analyze  B  attery 
Certifications  Data 

1.3. 2. 1.3  Analyze  Laser 
Certifications  Data 

1.3. 2. 1.4  Analyze  Weapon 
Certifications  Data 

1.3. 2. 1.5  Analyze  System 
Safety  Certifications  Data 

1.3. 2. 1.6  Analyze  Range 
Safety  Certifications  Data 

1.3. 2. 1.7  Analyze  E3 
Certification  Data 

1.3. 2.2.1  Analyze  IA 
Certifications  Data 

1.3. 2. 2. 2  Analyze  Anti- 
Tamper  Certifications  Data 

1.3. 2.2.3  Analyze  SAASM 
Certifications  Data 

1.3. 2. 2. 4  Analyze  Clinger- 
Cohen  Act  Certifications 
Data 

1.3. 2. 3.1  Analyze 

Spectrum  Certifications 

Data 

1.3. 2. 3. 2  Analyze  CDL 
Certifications  Data 

1.3. 2.3. 3  Analyze  JITC 
Certifications  Data 

1.3. 2.4.1  Analyze 
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Name 

Description 

refines 

refined  by 

basis  of 

Environmental 

Certifications  Data 

1.3. 2.4. 2  Analyze  T&E 
Certifications  Data 

1.2.3 

Design  Guidance  to 
Developer 

The  system  shall  output  the  needed  design 
changes  to  meet  certifications. 

1.2  OUTPUT 

1.3  Analyze  Certifications 

1.2.4 

Request  for  More 
Data  to  Developer 

The  system  shall  output  additional  data  need  to 
complete  certifications. 

1.2  OUTPUT 

1 . 1  Determine 
Certifications 

1.2  Collect  Certifications 

1.3  Analyze  Certifications 

1 .4  Address  Risk 

1.5  Develop  Certification 
Package 

1.2.5 

Certification 
Approval  Request 

The  system  shall  output  the  request  to  the 
certification  approval  authority  when  all 
technical  data  has  been  provided. 

1.2  OUTPUT 

1.5  Develop  Certification 
Package 

1.5.1  Develop  Safety 
Certification  Package 

1.5. 1.1  Develop 
Airworthiness 

Certifications  Package 

1.5. 1.2  Develop  Battery 
Certifications  Package 

1.5. 1.3  Develop  Laser 
Certifications  Package 

1.5. 1.4  Develop  Weapon 
Certifications  Package 

1.5. 1.5  Develop  System 

Safety  Certifications 

Package 

1.5. 1.6  Develop  Range 

Safety  Certifications 
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refines 

refined  by 

basis  of 

Package 

1.5. 1.7  Develop  E3 

Certification  Package 

1.5.2  Develop  Security 
Certifications  Package 

1.5. 2.1  Develop  IA 

Certifications  Package 

1. 5.2.2  Develop  Anti- 

Tamper  Certifications 

Package 

1. 5.2.3  Develop  SAASM 
Certifications  Package 

1.5. 2.4  Develop  Clinger- 
Cohen  Act  Certifications 
Package 

1.5.3  Develop 

Interoperability 

Certification  Package 

1.5. 3.1  Develop  Spectrum 
Certifications  Package 

1. 5.3.2  Develop  CDL 

Certifications  Package 

1. 5.3.3  Develop  JITC 

Certifications  Package 

1.5.4  Develop 

Compatibility 

Certifications  Package 

1.5. 4.1  Develop 
Environmental 

Certifications  Package 

1.5.4. 2  Develop  T&E 

Certifications  Package 
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Name 

Description 

refines 

refined  by 

basis  of 

1.2.6 

Packages  for 

Certification  (Initial 
&  Update) 

The  collection  of  documentation  needed  to 
apply  for  and  support  the  required 
certifications. 

1.2  OUTPUT 

1.2. 6.1  Initial  Data  Package 
for  Certification 

1. 2.6.2  Updated  Data  Package 
for  Certification 

1.5  Develop  Certification 
Package 

1.2. 6.1 

Initial  Data  Package 
for  Certification 

The  system  shall  output  data  packages  to  the 
certification  approval  authority  for  initial 
certification  request. 

1.2.6  Packages  for 
Certification  (Initial 
&  Update) 

1.5.1  Develop  Safety 

Certification  Package 

1.5.2  Develop  Security 

Certifications  Package 

1.5.3  Develop 
Interoperability 

Certification  Package 

1.5.4  Develop 
Compatibility 

Certifications  Package 

1.2. 6. 2 

Updated  Data 

Package  for 

Certification 

The  system  shall  output  data  packages  updates 
to  the  certification  approval  authority  as 
required  and  upon  request. 

1.2.6  Packages  for 
Certification  (Initial 
&  Update) 

1.5. 1.1  Develop 
Airworthiness 

Certifications  Package 

1 . 5 . 1 .2  Develop  Battery 
Certifications  Package 

1.5. 1.3  Develop  Laser 
Certifications  Package 

1.5. 1.4  Develop  Weapon 
Certifications  Package 

1.5. 1.5  Develop  System 

Safety  Certifications 

Package 

1.5. 1.6  Develop  Range 

Safety  Certifications 

Package 

1.5. 1.7  Develop  E3 

Certification  Package 

1.5. 2.1  Develop  IA 
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Name 

Description 

refines 

refined  by 

basis  of 

Certifications  Package 

1.5. 2. 2  Develop  Anti- 

Tamper  Certifications 

Package 

1. 5.2.3  Develop  SAASM 
Certifications  Package 

1.5. 2.4  Develop  Clinger- 
Cohen  Act  Certifications 
Package 

1.5. 3.1  Develop  Spectrum 
Certifications  Package 

1.5. 3. 2  Develop  CDL 

Certifications  Package 

1. 5.3.3  Develop  JITC 

Certifications  Package 

1.5. 4.1  Develop 
Environmental 

Certifications  Package 

1. 5.4.2  Develop  T&E 

Certifications  Package 

1.2.7 

Risk  Assessment 

The  assessment  of  the  residual  risk  including 
performance,  cost,  schedule,  and  safety. 

1.2  OUTPUT 

1 .4  Address  Risk 

1.4.1  Address  Safety 

Certifications  Risk 

1.4. 1.1  Address 
Airworthiness 

Certifications  Risk 

1.4. 1.2  Address  Battery 

Certifications  Risk 

1.4. 1.3  Address  Laser 
Certifications  Risk 

1.4. 1.4  Address  Weapon 
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Name 
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refines 

refined  by 

basis  of 

Certifications  Risk 

1.4. 1.5  Address  System 
Safety  Certifications  Risk 

1.4. 1.6  Address  Range 
Safety  Certifications  Risk 

1.4. 1.7  Address  E3 

Certifications  Risk 

1.4.2  Address  Security 
Certifications  Risk 

1. 4.2.1  Address  IA 

Certifications  Risk 

1. 4.2.2  Address  Anti- 

Tamper  Certifications  Risk 

1. 4.2.3  Address  SAASM 
Certifications  Risk 

1. 4.2.4  Address  Clinger- 
Cohen  Act  Certifications 
Risk 

1.4.3  Address 

Interoperability 

Certification  Risk 

1. 4.3.1  Address  Spectrum 
Certifications  Risk 

1.4.3. 2  Address  CDL 

Certifications  Risk 

1.4.3. 3  Address  JITC 

Certifications  Risk 

1.4.4  Address 

Compatibility  Certification 
Risk 

1. 4.4.1  Address 

Environmental 
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Name 
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refines 

refined  by 

basis  of 

Certifications  Risk 

1.4.4. 2  Address  T&E 

Certifications  Risk 

1.3 

EXTERNAL 

INTERFACE 

The  system  shall  interface  with  all  external 
entities  need  for  payload  intergration, 
certification  and  fielding. 

1  INPUT/OUTPUT 
REQUIREMENTS 

1.3.1  PMA-263 

1.3.2  T&E 

1.3.3  Certification  Authorities 

1.3.4  Developer 

0  STUAS  System 

1  Perform  Rain  Integration 
Process 

EXT.l  Address  PMA-263 
Activities 

EXT.  1.1  Define  User 
Needs 

EXT.  2  Provide 

Regulatory/ Statutory 
Requirements 

EXT.  3  Provide  Test  & 
Evaluation 

EXT.4  Perform 

Certifications  Review 

EXT. 5  Field  Payload 

1.3.1 

PMA-263 

The  system  shall  interface  with  PMA-263 
representatives. 

1.3  EXTERNAL 

INTERFACE 

EXT.l  Address  PMA-263 
Activities 

EXT.  1.2  Address 

Requirements 

EXT.  1.3  Develop  Payload 

EXT.  1 .4  Provide  System 
Integration 

EXT. 5  Field  Payload 

1.3.2 

T&E 

The  system  shall  interface  with  T&E 
representatives. 

1.3  EXTERNAL 

INTERFACE 

EXT.  3  Provide  Test  & 
Evaluation 

1.3.3 

Certification 

Authorities 

The  system  shall  interface  with  all 
representatives  required  for  system 

1.3  EXTERNAL 

INTERFACE 

1.3. 3.1  Internal  Certification 
SME’s 

EXT.2  Provide 

Regulatory/ Statutory 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

certification. 

Requirements 

EXT.4  Perform 

Certifications  Review 

1.3.3. 1 

Internal 

Certification  SME’s 

The  system  shall  interface  with  NAVAIR  and 
DoD  SMEs  as  need  for  certification. 

1.3.3  Certification 
Authorities 

EXT.4  Perform 

Certifications  Review 

1.3.4 

Developer 

The  system  shall  interface  with  payload  and 
platform  developers. 

1.3  EXTERNAL 

INTERFACE 

EXT.l  Address  PMA-263 
Activities 

EXT. 5  Field  Payload 

1.4 

FUNCTIONAL 

REQUIREMENTS 

The  system  shall  support  the  payload  meeting 
all  functional  requirements  outlined  below  for 
certification  and  operation. 

1  INPUT/OUTPUT 
REQUIREMENTS 

1.4.1  Show  Payload  Is  Ready 
to  be  Fielded 

1  Perform  Rain  Integration 
Process 

1.4.1 

Show  Payload  Is 
Ready  to  be  Fielded 

The  system  shall  provide  a  means  to  show  a 
payload  is  ready  to  be  fielded. 

1.4  FUNCTIONAL 
REQUIREMENTS 

1.4. 1.1  Comply  Payload  with 
Statutes  and  Regulations 

1.4. 1.2  Provide  Information 

Needed  to  Prove 

Interoperability 

1.4. 1.3  Provide  Information 
Needed  to  Prove  Safety 

1.4. 1.4  Provide  Information 
Needed  to  Prove  Security 

1.4. 1.5  Provide  Information 

Needed  to  Prove 

Environmental  Compatibility 

1 .4  Address  Risk 

1.5  Develop  Certification 
Package 

1.4.1. 1 

Comply  Payload 

with  Statutes  and 
Regulations 

The  system  shall  provide  a  means  to  have  the 
payload  comply  with  statutes  and  regulations. 

1.4.1  Show  Payload 
Is  Ready  to  be 
Fielded 

1.4. 1.1.1  Determine 
Certifications  Needed 

1.4. 1.1. 2  Collect  Data  to 
Support  Certification 

1.4. 1.1. 3  Evaluate  Pre- 
Submission  Certification  Data 
Package 

1.4. 1.1. 4  Means  to  Use  to 

1.5  Develop  Certification 
Package 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

Interface  with  Tech  Cert 
Authorities 

1.4.1. 1.1 

Determine 

Certifications 

Needed 

The  system  shall  provide  a  means  to  determine 
the  certifications  needed  based  on  the 
capabilities  of  the  new  payload. 

1.4. 1.1  Comply 

Payload  with 

Statutes  and 

Regulations 

1.4. 1.1. 1.1  Provide  Means  to 
Track  That  All  Certifications 
Are  Addressed 

1 . 1  Determine 

Certifications 

1.4.1. 1.1. 

1 

Provide  Means  to 
Track  That  All 
Certifications  Are 
Addressed 

The  system  shall  provide  a  means  to  track  that 
all  certifications  are  addressed. 

1.4. 1.1.1  Determine 
Certifications 

Needed 

1.1.1  Construct 
Certification  List 

1.1.2  Assemble 
Certification  Components 

1.1.3  Sort  Certification  List 

1.4.1. 1.2 

Collect  Data  to 
Support 

Certification 

The  system  shall  provide  a  means  to  collect  the 
data  needed  to  support  each  of  the  required 
certifications. 

1.4. 1.1  Comply 

Payload  with 

Statutes  and 

Regulations 

1.2.3  Perform  Data 

Collection 

1. 2.3.1  Collect  Safety 
Certification  Data 

1.2. 3. 2  Collect  Security 
Certification  Data 

1.2.3. 3  Collect 
Interoperability 

Certification  Data 

1.2.3. 4  Collect 
Compatibility  Certification 
Data 

1.4.1. 1.3 

Evaluate  Pre- 

Submission 
Certification  Data 
Package 

The  system  shall  provide  a  means  to  evaluate 
the  pre-submission  data  package  for  each 
technical  certification  for  adequacy. 

1.4. 1.1  Comply 

Payload  with 

Statutes  and 

Regulations 

1.3.2  Provide  Analysis 

1.3. 2.1  Analyze  Safety 
Certification  Data 

1.3. 2. 1.1  Analyze 
Airworthiness 

Certifications  Data 

1.3. 2. 1.2  Analyze  Battery 
Certifications  Data 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

1.3. 2. 1.3  Analyze  Laser 
Certifications  Data 

1.3. 2. 1.4  Analyze  Weapon 
Certifications  Data 

1.3. 2. 1.5  Analyze  System 
Safety  Certifications  Data 

1.3. 2. 1.6  Analyze  Range 
Safety  Certifications  Data 

1.3. 2. 1.7  Analyze  E3 
Certification  Data 

1.3. 2.2  Analyze  Security 
Certifications  Data 

1.3. 2. 2.1  Analyze  I A 
Certifications  Data 

1.3. 2. 2. 2  Analyze  Anti- 
Tamper  Certifications  Data 

1.3. 2.2.3  Analyze  SAASM 
Certifications  Data 

1.3.2.2.4  Analyze  Clinger- 
Cohen  Act  Certifications 
Data 

1.3. 2. 3  Analyze 

Interoperability 
Certifications  Data 

1.3. 2. 3.1  Analyze 

Spectrum  Certifications 

Data 

1.3. 2. 3. 2  Analyze  CDL 
Certifications  Data 

1.3. 2.3. 3  Analyze  JITC 
Certifications  Data 

1.3. 2. 4  Analyze 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

Compatibility  Certification 
Data 

1.3. 2.4.1  Analyze 
Environmental 

Certifications  Data 

1.3. 2.4.2  Analyze  T&E 
Certifications  Data 

1.4.1. 1.4 

Means  to  Use  to 
Interface  with  Tech 
Cert  Authorities 

The  system  shall  provide  the  means  of 
interfacing  with  the  technical  certification 
authorities. 

1.4. 1.1  Comply 

Payload  with 

Statutes  and 

Regulations 

1.4. 1.1. 4.1  Provide  Process 
for  Complying  with  Tech  Cert 
Authority  Guidance 

1.5  Develop  Certification 
Package 

1.5.1  Develop  Safety 

Certification  Package 

1.5.2  Develop  Security 

Certifications  Package 

1.5.3  Develop 
Interoperability 

Certification  Package 

1.5.4  Develop 
Compatibility 

Certifications  Package 

1.4.1. 1.4. 

1 

Provide  Process  for 
Complying  with 

Tech  Cert  Authority 
Guidance 

The  system  shall  provide  the  process  for 
complying  with  the  guidance  from  the  technical 
certification  authority. 

1.4. 1.1. 4  Means  to 

Use  to  Interface  with 
Tech  Cert 

Authorities 

2. 2. 1.1. 4  Aggregated 
Risk  Level  from  Use 
of  Waiver  &  Interim 
Approvals 

1.5. 1.1  Develop 
Airworthiness 

Certifications  Package 

1.5. 1.2  Develop  Battery 
Certifications  Package 

1.5. 1.3  Develop  Laser 
Certifications  Package 

1.5. 1.4  Develop  Weapon 
Certifications  Package 

1.5. 1.5  Develop  System 

Safety  Certifications 

Package 

1.5. 1.6  Develop  Range 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

Safety  Certifications 

Package 

1.5. 1.7  Develop  E3 

Certification  Package 

1.5. 2.1  Develop  IA 

Certifications  Package 

1.5. 2. 2  Develop  Anti- 

Tamper  Certifications 

Package 

1. 5.2.3  Develop  SAASM 
Certifications  Package 

1. 5.2.4  Develop  Clinger- 
Cohen  Act  Certifications 
Package 

1.5. 3.1  Develop  Spectrum 
Certifications  Package 

1.5. 3. 2  Develop  CDL 

Certifications  Package 

1. 5.3.3  Develop  JITC 

Certifications  Package 

1.5. 4.1  Develop 
Environmental 

Certifications  Package 

1.5.4. 2  Develop  T&E 

Certifications  Package 

1.4. 1.2 

Provide  Information 
Needed  to  Prove 
Interoperability 

The  system  shall  provide  the  information 
needed  to  prove  Interoperability. 

1.4.1  Show  Payload 
Is  Ready  to  be 
Fielded 

1.1. 2.3  Determine 

Interoperability 

Certifications 

1.1. 2. 3.1  Address 
Spectrum  Certifications 

1.1. 2.3. 2  Address  CDL 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

Certifications 

1.1. 2.3. 3  Address  JITC 
Certifications 

1.2.3. 3  Collect 
Interoperability 

Certification  Data 

1.2. 3. 3.1  Collect  Spectrum 
Certifications  Data 

1.2.3. 3. 2  Collect  CDL 

Certifications  Data 

1.2.3. 3. 3  Collect  JITC 

Certifications  Data 

1.3. 2. 3  Analyze 
Interoperability 
Certifications  Data 

1.3. 2. 3.1  Analyze 

Spectrum  Certifications 

Data 

1.3. 2. 3. 2  Analyze  CDL 

Certifications  Data 

1.3. 2.3. 3  Analyze  JITC 

Certifications  Data 

1.4.3  Address 
Interoperability 

Certification  Risk 

1.4. 3.1  Address  Spectrum 
Certifications  Risk 

1.4.3. 2  Address  CDL 
Certifications  Risk 

1.4.3. 3  Address  JITC 
Certifications  Risk 

1.5.3  Develop 

Ill 


Number 

Name 

Description 

refines 

refined  by 

basis  of 

Interoperability 

Certification  Package 

1.5. 3.1  Develop  Spectrum 
Certifications  Package 

1. 5.3.2  Develop  CDL 

Certifications  Package 

1. 5.3.3  Develop  JITC 

Certifications  Package 

1.4.1 .3 

Provide  Information 
Needed  to  Prove 
Safety 

The  system  shall  provide  the  information 
needed  to  prove  Safety. 

1.4.1  Show  Payload 
Is  Ready  to  be 
Fielded 

1.1. 2.1  Determine  Safety 
Certifications 

1.1. 2. 1.1  Address 
Airworthiness 

Certifications 

1.1. 2. 1.2  Address  Battery 
Certifications 

1.1. 2. 1.3  Address  Laser 
Certifications 

1.1. 2. 1.4  Address  Weapon 
Certifications 

1.1. 2. 1.5  Address  System 
Safety  Certifications 

1. 2.3.1  Collect  Safety 
Certification  Data 

1.2.3. 1.1  Collect 
Airworthiness 

Certifications  Data 

1.2. 3. 1.2  Collect  Battery 
Certifications  Data 

1.2.3. 1.3  Collect  Laser 
Certifications  Data 

1.2.3. 1.4  Collect  Weapon 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

Certifications  Data 

1.2.3. 1.5  Collect  System 
Safety  Certifications  Data 

1.3. 2.1  Analyze  Safety 
Certification  Data 

1.3. 2. 1.1  Analyze 
Airworthiness 

Certifications  Data 

1 . 3 . 2 . 1 . 2  Analyze  B  attery 
Certifications  Data 

1.3. 2. 1.3  Analyze  Laser 
Certifications  Data 

1.3. 2. 1.4  Analyze  Weapon 
Certifications  Data 

1.3. 2. 1.5  Analyze  System 
Safety  Certifications  Data 

1.4.1  Address  Safety 

Certifications  Risk 

1.4. 1.1  Address 
Airworthiness 

Certifications  Risk 

1.4. 1.2  Address  Battery 
Certifications  Risk 

1.4. 1.3  Address  Laser 
Certifications  Risk 

1.4. 1.4  Address  Weapon 
Certifications  Risk 

1.4. 1.5  Address  System 
Safety  Certifications  Risk 

1.5.1  Develop  Safety 
Certification  Package 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

1.5. 1.1  Develop 
Airworthiness 

Certifications  Package 

1 . 5 . 1 .2  Develop  Battery 
Certifications  Package 

1.5. 1.3  Develop  Laser 
Certifications  Package 

1.5. 1.4  Develop  Weapon 
Certifications  Package 

1.5. 1.5  Develop  System 

Safety  Certifications 

Package 

1.4. 1.4 

Provide  Information 
Needed  to  Prove 
Security 

The  system  shall  provide  the  information 
needed  to  prove  Security. 

1.4.1  Show  Payload 
Is  Ready  to  be 
Fielded 

1.1. 2.2  Determine  Security 
Certifications 

1.1. 2.2.1  Address  IA 
Certifications 

1.1. 2. 2. 2  Address  Anti- 
Tamper  Certifications 

1.1. 2.2.3  Address  SAASM 
Certifications 

1.1. 2. 2. 4  Address  Clinger- 
Cohen  Act  Certifications 

1.2.3. 2  Collect  Security 
Certification  Data 

1.2.3. 2.1  Collect  IA 

Certifications  Data 

1.2. 3. 2. 2  Collect  Anti- 
Tamper  Certifications  Data 

1.2.3. 2.3  Collect  SAASM 
Certifications  Data 

1.2. 3. 2. 4  Collect  Clinger- 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

Cohen  Act  Certifications 
Data 

1. 3.2.2  Analyze  Security 
Certifications  Data 

1.3. 2.2.1  Analyze  IA 
Certifications  Data 

1.3. 2. 2. 2  Analyze  Anti- 
Tamper  Certifications  Data 

1.3. 2.2.3  Analyze  SAASM 
Certifications  Data 

1.3.2.2.4  Analyze  Clinger- 
Cohen  Act  Certifications 
Data 

1.4.2  Address  Security 
Certifications  Risk 

1. 4.2.1  Address  IA 

Certifications  Risk 

1.4. 2. 2  Address  Anti- 
Tamper  Certifications  Risk 

1. 4.2.3  Address  SAASM 
Certifications  Risk 

1. 4.2.4  Address  Clinger- 
Cohen  Act  Certifications 
Risk 

1.5.2  Develop  Security 
Certifications  Package 

1.5. 2.1  Develop  IA 

Certifications  Package 

1.5. 2. 2  Develop  Anti- 

Tamper  Certifications 

Package 

1. 5.2.3  Develop  SAASM 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

Certifications  Package 

1.5. 2.4  Develop  Clinger- 
Cohen  Act  Certifications 
Package 

1.4.1. 5 

Provide  Information 
Needed  to  Prove 
Environmental 
Compatibility 

The  system  shall  provide  the  information 
needed  to  prove  Environmental  Compatibility. 

1.4.1  Show  Payload 
Is  Ready  to  be 
Fielded 

1.1. 2. 4  Determine 
Compatibility 

Certifications 

1.1. 2.4.1  Address 
Environmental 

Certifications 

1.1. 2.4.2  Address  T&E 
Certifications 

1.2.3. 4  Collect 
Compatibility  Certification 
Data 

1.2.3. 4.1  Collect 
Environmental 

Certifications  Data 

1.3. 2. 4  Analyze 
Compatibility  Certification 
Data 

1.3. 2.4.1  Analyze 
Environmental 

Certifications  Data 

1.3. 2.4.2  Analyze  T&E 
Certifications  Data 

1.4.4  Address 
Compatibility  Certification 
Risk 

1. 4.4.1  Address 
Environmental 

Certifications  Risk 

1. 4.4.2  Address  T&E 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

Certifications  Risk 

1.5.4  Develop 

Compatibility 

Certifications  Package 

1.5. 4.1  Develop 
Environmental 

Certifications  Package 

1. 5.4.2  Develop  T&E 
Certifications  Package 

2 

TECHNOLOGY  & 

SYSTEM-WIDE 

REQUIREMENTS 

The  system  shall  include  system  Technology; 
Suitability  and  Quality;  Cost;  Schedule  to 
support  RAIN  Process. 

0  REQUIREMENTS 
CONTEXT 

2.1  TECHNOLOGY 
CONSTRAINTS 

2.2  SUITABILITY  & 

QUALITY 

2.3  COST  REQUIERMENTS 

2.4  SCHEDULE 
REQUIREMENTS 

1  Perform  Rain  Integration 
Process 

2.1 

TECHNOLOGY 

CONSTRAINTS 

The  system  shall  support  the  following 
technology  requirements. 

2  TECHNOLOGY 
&  SYSTEM-WIDE 
REQUIREMENTS 

2.1.1  NMCI 

2.1.2  Email 

2.1.3  MS  Office 

2.1.4  PMA-263  Database(s) 

1  Perform  Rain  Integration 
Process 

2.1.1 

NMCI 

the  computer  network  based  information 
exchange  shall  operate  within  the  limits  of  what 
the  NMCI  will  allow  or  support. 

2.1  TECHNOLOGY 
CONSTRAINTS 

1  Perform  Rain  Integration 
Process 

2.1.2 

Email 

Written  communication  of  the  system 
information  shall  be  through  DoD  approved 
encrypted  email 

2.1  TECHNOLOGY 
CONSTRAINTS 

1  Perform  Rain  Integration 
Process 

2.1.3 

MS  Office 

The  system  documentation  shall  be  limited  to 
being  in  MS  Office  formats  (MS  Word  2003, 
MS  Excel  2003,  or  MS  Power  Point  2003 
formats). 

2.1  TECHNOLOGY 
CONSTRAINTS 

1  Perform  Rain  Integration 
Process 
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Name 

Description 

refines 

refined  by 

basis  of 

2.1.4 

PMA-263 

Database(s) 

File  sharing  shall  be  limited  to  PMA-263  and 
DoD  approved  contractor  databases. 

2.1  TECHNOLOGY 
CONSTRAINTS 

1  Perform  Rain  Integration 
Process 

2.2 

SUITABILITY  & 
QUALITY 

The  system  shall  support  the  following 
suitability  and  quality  requirements  for 
operation. 

2  TECHNOLOGY 
&  SYSTEM-WIDE 
REQUIREMENTS 

2.2.1  Produces  Complete 

Decision  Package 

2.2.2  Produces  Accurate 

Decision  Package 

1  Perform  Rain  Integration 
Process 

2.2.1 

Produces  Complete 
Decision  Package 

The  system  shall  produce  complete  fielding 
decision  packages 

2.2  SUITABILITY 
&  QUALITY 

2. 2. 1.1  Addresses  All 

Relevant  Statutes  and 

Regulations 

2. 2. 1.2  Justifies  Omitted 
Statutes  or  Regulations 

1 . 1  Determine 

Certifications 

1 .4  Address  Risk 

1.5  Develop  Certification 
Package 

2.2.1. 1 

Addresses  All 

Relevant  Statutes 
and  Regulations 

The  system  shall  address  all  relevant  statutes 
and  regulations. 

2.2.1  Produces 

Complete  Decision 
Package 

2. 2. 1.1.1  Tailored  List  of 
Required  Certs  by  Payload 
System  Type 

2. 2. 1.1. 2  Certifications, 
Approvals,  Letter,  or  Waiver 
for  All  Required  Statutes  & 
Regulations 

2. 2. 1.1. 3  Instructions  on  The 
Order  &  Start  Times  for  Each 
Cert 

2. 2. 1.1. 4  Aggregated  Risk 
Level  from  Use  of  Waiver  & 
Interim  Approvals 

1.1. 2.1  Determine  Safety 
Certifications 

1.1. 2. 2  Determine  Security 
Certifications 

1.1. 2. 3  Determine 
Interoperability 
Certifications 

1.1. 2. 4  Determine 
Compatibility 

Certifications 

1.4.1  Address  Safety 
Certifications  Risk 

1.4.2  Address  Security 
Certifications  Risk 

1.4.3  Address 
Interoperability 

Certification  Risk 

1.4.4  Address 
Compatibility  Certification 
Risk 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

1.5.1  Develop  Safety 

Certification  Package 

1.5.2  Develop  Security 

Certifications  Package 

1.5.3  Develop 
Interoperability 

Certification  Package 

1.5.4  Develop 
Compatibility 

Certifications  Package 

2.2.1. 1.1 

Tailored  List  of 
Required  Certs  by 
Payload  System 

Type 

The  system  shall  provide  a  tailored  list  of 
required  certs  by  payload  system  type. 

2. 2. 1.1  Addresses 

All  Relevant  Statutes 
and  Regulations 

1.1. 2. 1.1  Address 
Airworthiness 

Certifications 

1.1. 2. 1.2  Address  Battery 
Certifications 

1.1. 2. 1.3  Address  Laser 
Certifications 

1.1. 2. 1.4  Address  Weapon 
Certifications 

1.1. 2. 1.5  Address  System 
Safety  Certifications 

1.1. 2. 1.6  Address  Range 
Safety  Certifications 

1.1. 2. 1.7  Address  E3 
Certifications 

1.1. 2.2.1  Address  IA 
Certifications 

1.1. 2. 2. 2  Address  Anti- 
Tamper  Certifications 

1.1. 2.2.3  Address  SAASM 
Certifications 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

1.1. 2.2.4  Address  Clinger- 
Cohen  Act  Certifications 

1.1. 2. 3.1  Address 
Spectrum  Certifications 

1.1. 2.3. 2  Address  CDL 

Certifications 

1.1. 2.3. 3  Address  JITC 

Certifications 

1.1. 2.4.1  Address 
Environmental 

Certifications 

1.1. 2.4.2  Address  T&E 

Certifications 

2.2.1. 1.2 

Certifications, 
Approvals,  Letter, 
or  Waiver  for  All 
Required  Statutes  & 
Regulations 

The  system  shall  provide  the  Certifications, 
approvals,  letter,  or  waiver  for  all  required 
statutes  and  regulations. 

2. 2. 1.1  Addresses 

All  Relevant  Statutes 
and  Regulations 

1.5. 1.1  Develop 
Airworthiness 

Certifications  Package 

1 . 5 . 1 .2  Develop  Battery 
Certifications  Package 

1.5. 1.3  Develop  Laser 
Certifications  Package 

1.5. 1.4  Develop  Weapon 
Certifications  Package 

1.5. 1.5  Develop  System 

Safety  Certifications 

Package 

1.5. 1.6  Develop  Range 

Safety  Certifications 

Package 

1.5. 1.7  Develop  E3 

Certification  Package 

1.5. 2.1  Develop  IA 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

Certifications  Package 

1.5. 2. 2  Develop  Anti- 

Tamper  Certifications 

Package 

1. 5.2.3  Develop  SAASM 
Certifications  Package 

1.5. 2.4  Develop  Clinger- 
Cohen  Act  Certifications 
Package 

1.5. 3.1  Develop  Spectrum 
Certifications  Package 

1.5. 3. 2  Develop  CDL 

Certifications  Package 

1. 5.3.3  Develop  JITC 

Certifications  Package 

1.5. 4.1  Develop 
Environmental 

Certifications  Package 

1. 5.4.2  Develop  T&E 

Certifications  Package 

2.2.1. 1.3 

Instructions  on  The 
Order  &  Start 
Times  for  Each  Cert 

The  system  shall  provide  instructions  on  the 
order  and  relative  start  times  for  each 
certification. 

2. 2. 1.1  Addresses 

All  Relevant  Statutes 
and  Regulations 

1.1. 2. 1.1  Address 
Airworthiness 

Certifications 

1.1. 2. 1.2  Address  Battery 
Certifications 

1.1. 2. 1.3  Address  Laser 
Certifications 

1.1. 2. 1.4  Address  Weapon 
Certifications 

1.1. 2. 1.5  Address  System 
Safety  Certifications 
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1.1. 2. 1.6  Address  Range 
Safety  Certifications 

1.1. 2. 1.7  Address  E3 
Certifications 

1.1. 2.2.1  Address  IA 
Certifications 

1.1. 2. 2. 2  Address  Anti- 
Tamper  Certifications 

1.1. 2.2.3  Address  SAASM 
Certifications 

1.1. 2.2.4  Address  Clinger- 
Cohen  Act  Certifications 

1.1. 2.3.1  Address 
Spectrum  Certifications 

1.1. 2.3. 2  Address  CDL 

Certifications 

1.1. 2.3. 3  Address  JITC 

Certifications 

1.1. 2.4.1  Address 
Environmental 

Certifications 

1.1. 2.4.2  Address  T&E 

Certifications 

2.2.1. 1.4 

Aggregated  Risk 

Level  from  Use  of 
Waiver  &  Interim 
Approvals 

The  system  shall  provide  aggregated  risk  level 
analysis  from  the  use  of  the  waiver  and  interim 
approvals. 

2. 2. 1.1  Addresses 

All  Relevant  Statutes 
and  Regulations 

1.4. 1.1. 4.1  Provide  Process 
for  Complying  with  Tech  Cert 
Authority  Guidance 

1.4. 1.1  Address 
Airworthiness 

Certifications  Risk 

1.4. 1.2  Address  Battery 
Certifications  Risk 

1.4. 1.3  Address  Laser 
Certifications  Risk 

1.4. 1.4  Address  Weapon 
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refines 

refined  by 

basis  of 

Certifications  Risk 

1.4. 1.5  Address  System 

Safety  Certifications  Risk 

1.4. 1.6  Address  Range 

Safety  Certifications  Risk 

1.4. 1.7  Address  E3 

Certifications  Risk 

1. 4.2.1  Address  IA 

Certifications  Risk 

1.4. 2. 2  Address  Anti- 

Tamper  Certifications  Risk 

1. 4.2.3  Address  SAASM 
Certifications  Risk 

1. 4.2.4  Address  Clinger- 
Cohen  Act  Certifications 
Risk 

1.4. 3.1  Address  Spectrum 
Certifications  Risk 

1.4.3. 2  Address  CDL 

Certifications  Risk 

1.4.3. 3  Address  JITC 

Certifications  Risk 

1. 4.4.1  Address 
Environmental 

Certifications  Risk 

1. 4.4.2  Address  T&E 

Certifications  Risk 

2.2.1. 1.4. 

1 

Instructions  on  The 
Risks  of  Using 
Waivers  or  Interim 
Approvals 

The  system  shall  provide  instructions  on  the 
risks  level  of  using  waivers  or  interim 
approvals. 

1.4. 1.1  Address 
Airworthiness 

Certifications  Risk 

1.4. 1.2  Address  Battery 
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refined  by 
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Certifications  Risk 

1.4. 1.3  Address  Laser 

Certifications  Risk 

1.4. 1.4  Address  Weapon 
Certifications  Risk 

1.4. 1.5  Address  System 

Safety  Certifications  Risk 

1.4. 1.6  Address  Range 

Safety  Certifications  Risk 

1.4. 1.7  Address  E3 

Certifications  Risk 

1. 4.2.1  Address  IA 

Certifications  Risk 

1.4. 2. 2  Address  Anti- 

Tamper  Certifications  Risk 

1. 4.2.3  Address  SAASM 
Certifications  Risk 

1. 4.2.4  Address  Clinger- 
Cohen  Act  Certifications 
Risk 

1. 4.3.1  Address  Spectrum 
Certifications  Risk 

1.4.3. 2  Address  CDL 

Certifications  Risk 

1.4.3. 3  Address  JITC 

Certifications  Risk 

1. 4.4.1  Address 
Environmental 

Certifications  Risk 

1.4.4. 2  Address  T&E 

Certifications  Risk 
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Number 

Name 

Description 

refines 

refined  by 

basis  of 

2.2. 1.2 

Justifies  Omitted 
Statutes  or 

Regulations 

The  system  shall  provide  the  justification  for 
omitted  certifications  (statutes  and/or 

regulations  certifications). 

2.2.1  Produces 

Complete  Decision 
Package 

1 . 1  Determine 
Certifications 

1.1.1  Construct 
Certification  List 

1.1.2  Assemble 
Certification  Components 

1.1.3  Sort  Certification  List 

2.2.2 

Produces  Accurate 
Decision  Package 

The  system  shall  produce  complete  accurate 
fielding  decision  packages. 

2.2  SUITABILITY 
&  QUALITY 

1  Perform  Rain  Integration 
Process 

1 . 1  Determine 
Certifications 

1.2  Collect  Certifications 

1.3  Analyze  Certifications 

1 .4  Address  Risk 

1.5  Develop  Certification 
Package 

2.3 

COST 

REQUIERMENTS 

The  costs  requirements  are  detailed  in  the  lower 
level  requirements. 

2  TECHNOLOGY 
&  SYSTEM-WIDE 
REQUIREMENTS 

2.3.1  Same  or  Lower  Than 
Current  Cost  est<$2M 

1  Perform  Rain  Integration 
Process 

2.3.1 

Same  or  Lower 
Than  Current  Cost 
est<$2M 

The  system  shall  incur  the  same  or  lower  costs 
as  the  current  processes  used  to  fully  support 
payload  fielding  decisions,  to  less  than 
$2Million. 

2.3  COST 

REQUIERMENTS 

1  Perform  Rain  Integration 
Process 

2.4 

SCHEDULE 

REQUIREMENTS 

The  schedule  requirements  are  detailed  in  the 
lower  level  requirements. 

2  TECHNOLOGY 
&  SYSTEM-WIDE 
REQUIREMENTS 

2.4.1  Less  Than  18  Mths  to 
Produce  The  Fielding 

Decision  Package 

1  Perform  Rain  Integration 
Process 

2.4.1 

Less  Than  18  Mths 
to  Produce  The 
Fielding  Decision 
Package 

The  system  shall  provide  an  option  to  take  18 
months  or  less  to  produce  the  fielding  decision 
package. 

2.4  SCHEDULE 

REQUIREMENTS 

1  Perform  Rain  Integration 
Process 

3 

TRADE-OFF 

The  system  shall  address  the  fundamental 

0  REQUIREMENTS 

3.1  PERFORMANCE 

1  Perform  Rain  Integration 
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REQUIREMENTS 

objectives  hierarchy  indicate  the  weighted 
values  for  each  bottom  level  objective  for  use  in 
trading  off  features  used  during  operations,  but 
implemented  during  development  and 
manufacturing. 

CONTEXT 

TRADE-OFF 

3.2  COST  TRADE-OFF 

3.3  COST-PERFORMANCE 
TRADE-OFF 

Process 

3.1 

PERFORMANCE 

TRADE-OFF 

The  system  shall  perform  a  trade-off  analysis 
based  on  the  factors  identified  in  The  systems 
fundamental  objectives  hierarchy. 

3  TRADE-OFF 

REQUIREMENTS 

3.1.1  Minimize  Time  to 

Address  Statutory  & 

Regulatory  Requirements  for 
Fielding 

3.1.2  Provide  Means  to 
Manage  Risks 

1  Perform  Rain  Integration 
Process 

3.1.1 

Minimize  Time  to 
Address  Statutory 
&  Regulatory 

Requirements  for 
Fielding 

The  system  shall  minimize  time  to  address 
statutory  and  regulatory  requirements  for 
fielding. 

3.1 

PERFORMANCE 

TRADE-OFF 

3. 1.1.1  Minimize  Time  to 

Determine  Certifications 

Required  to  Pursue 

3. 1.1. 2  Minimize  Time  to 

Address  Required 

Certifications 

1  Perform  Rain  Integration 
Process 

3.1. 1.1 

Minimize  Time  to 
Determine 
Certifications 
Required  to  Pursue 

The  system  shall  minimize  time  to  determine 
certifications  required  to  be  pursued. 

3.1.1  Minimize  Time 
to  Address  Statutory 
&  Regulatory 

Requirements  for 

Fielding 

3. 1.1. 1.1  Time  to  Determine 
Needed  Certifications  Value 
Curve  Is  Linear  with  a  Value 
of  1  at  One  Day  or  Less  & 
Zero  at  One  Year 

1  Perform  Rain  Integration 
Process 

3.1. 1.1.1 

Time  to  Determine 
Needed 

Certifications  Value 
Curve  Is  Linear 
with  a  Value  of  1  at 
One  Day  or  Less  & 
Zero  at  One  Year 

The  system  shall  value  the  time  to  determine 
needed  certifications  with  a  value  curve  that  is 
linear  with  a  value  of  1  at  one  day  or  less  and 
zero  at  one  year. 

3. 1.1.1  Minimize 

Time  to  Determine 
Certifications 
Required  to  Pursue 

3. 1.1. 1.1.1  Weight  15%  for 
Minimize  Time  to  Determine 
Certifications 

1  Perform  Rain  Integration 
Process 

3.1. 1.1.1. 

1 

Weight  15%  for 
Minimize  Time  to 
Determine 
Certifications 

The  system  shall  apply  a  trade  weight  of  15% 
to  minimizing  the  time  to  determine  required 
certifications  when  de-conflicting  with  other 
trade-off  requirements. 

3. 1.1. 1.1  Time  to 
Determine  Needed 
Certifications  Value 
Curve  Is  Linear  with 
a  Value  of  1  at  One 
Day  or  Less  &  Zero 

1  Perform  Rain  Integration 
Process 
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at  One  Year 

3.1. 1.2 

Minimize  Time  to 
Address  Required 
Certifications 

The  system  shall  minimize  time  to  address 
required  certifications. 

3.1.1  Minimize  Time 
to  Address  Statutory 
&  Regulatory 

Requirements  for 

Fielding 

3. 1.1. 2.1  Time  to  obtain 

waiver  s/interim  approvals 

value  curve  is  linear  with  a 
value  of  1  at  one  day  or  less 
and  zero  at  one  year. 

3. 1.1. 2. 2  Time  to  obtain  full 
certification  approvals  value 
curve  is  linear  with  a  value  of 

1  at  one  day  or  less  and  zero 
at  one  year. 

1  Perform  Rain  Integration 
Process 

3.1. 1.2.1 

Time  to  obtain 
waiver  s/interim 
approvals  value 

curve  is  linear  with 
a  value  of  1  at  one 
day  or  less  and  zero 
at  one  year. 

The  system  shall  value  the  time  to  obtain 
waiver  s/interim  approvals  with  a  value  curve 
that  is  linear  with  a  value  of  1  at  one  day  or  less 
and  zero  at  one  year. 

3. 1.1. 2  Minimize 

Time  to  Address 
Required 
Certifications 

3.1. 1.2.1. 1  Weight  35%  for 
Minimize  Time  to  Obtain 
Waiver/Interim  Approvals. 

1  Perform  Rain  Integration 
Process 

3.1. 1.2.1. 

1 

Weight  35%  for 
Minimize  Time  to 
Obtain 

Waiver/Interim 

Approvals. 

The  system  shall  apply  a  trade  weight  of  35% 
to  minimizing  the  time  to  obtain 
waiver  s/interim  approvals  when  de-conflicting 
with  other  trade-off  requirements. 

3. 1.1. 2.1  Time  to 
obtain 

waiver  s/interim 
approvals  value 

curve  is  linear  with  a 
value  of  1  at  one  day 
or  less  and  zero  at 
one  year. 

1  Perform  Rain  Integration 
Process 

3.1. 1.2.2 

Time  to  obtain  full 
certification 
approvals  value 

curve  is  linear  with 
a  value  of  1  at  one 
day  or  less  and  zero 
at  one  year. 

The  system  shall  value  the  time  to  obtain  full 
certification  approvals  with  value  curve  that  is 
linear  with  a  value  of  1  at  one  day  or  less  and 
zero  at  one  year. 

3. 1.1. 2  Minimize 

Time  to  Address 
Required 
Certifications 

3.1. 1.2.2. 1  Weight  35%  for 
Minimize  Time  to  Obtain  Full 
Certification  Approval 

1  Perform  Rain  Integration 
Process 

3.1. 1.2.2. 

1 

Weight  35%  for 
Minimize  Time  to 
Obtain  Full 

The  system  shall  apply  a  trade  weight  of  35% 
to  minimizing  the  time  to  obtain  full 
certification  approvals  when  de-conflicting  with 

3. 1.1. 2. 2  Time  to 
obtain  full 

certification 

1  Perform  Rain  Integration 
Process 
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Certification 

Approval 

other  trade-off  requirements. 

approvals  value 

curve  is  linear  with  a 
value  of  1  at  one  day 
or  less  and  zero  at 
one  year. 

3.1.2 

Provide  Means  to 
Manage  Risks 

The  system  shall  provide  a  means  to  manage 
risks. 

3.1 

PERFORMANCE 

TRADE-OFF 

3. 1.2.1  Minimize  waivers  and 
interim  approvals 

1  Perform  Rain  Integration 
Process 

3. 1.2.1 

Minimize  waivers 
and  interim 

approvals 

The  system  shall  minimize  waivers  and  interim 
approvals. 

3.1.2  Provide  Means 
to  Manage  Risks 

3. 1.2. 1.1  Percentage  of 

waiver  s/interims  value  cure  is 
linear  with  value  of  1  at  0% 
and  0  at  100%. 

1  Perform  Rain  Integration 
Process 

3. 1.2.1. 1 

Percentage  of 

waiver  s/interims 
value  cure  is  linear 
with  value  of  1  at 
0%  and  0  at  100%. 

The  system  shall  value  the  percentage  of 
waiver  s/interims  with  a  value  cure  that  is  linear 
with  value  of  1  at  0%  and  0  at  100%. 

3. 1.2.1  Minimize 

waivers  and  interim 
approvals 

3. 1.2.1. 1.1  Weight  15% 
Percentage  of 

Waivers/Interims  Approvals 

1  Perform  Rain  Integration 
Process 

3. 1.2.1. 1. 

1 

Weight  15% 

Percentage  of 

W  ai  vers/interims 
Approvals 

The  system  shall  apply  a  trade  weight  of  15% 
to  minimizing  the  percentage  of 

waiver  s/interims  when  deconfliction  with  other 
trade-off  requirements. 

3. 1.2. 1.1  Percentage 
of  waiver  s/interims 
value  cure  is  linear 
with  value  of  1  at  0% 
and  0  at  100%. 

1  Perform  Rain  Integration 
Process 

3.2 

COST  TRADE¬ 

OFF 

The  first  phase  of  this  systems  development 
shall  not  address  this  phase. 

3  TRADE-OFF 

REQUIREMENTS 

3.2.1  Cost 

1  Perform  Rain  Integration 
Process 

3.2.1 

Cost 

N/A. 

3.2  COST  TRADE¬ 
OFF 

1  Perform  Rain  Integration 
Process 

3.3 

COST- 

PERFORMANCE 

TRADE-OFF 

The  first  phase  of  this  systems  development 
shall  not  address  this  phase. 

3  TRADE-OFF 

REQUIREMENTS 

3.3.1  Cost-Performance 

1  Perform  Rain  Integration 
Process 

3.3.1 

Cost-Performance 

N/A. 

3.3  COST- 

PERFORMANCE 

TRADE-OFF 

1  Perform  Rain  Integration 
Process 

4 

QUALIFICATION 

Requirements  on  observing  and  collecting  data 
from  tests,  how  the  collected  data  will  be  used 

0  REQUIREMENTS 

4.1  OBSERVANCE 

1  Perform  Rain  Integration 
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REQUIREMENTS 

to  verify  the  RAIN  works  as  specified,  how 
RAIN  will  be  validated  to  meet  user  needs,  and 
how  RAIN  will  be  determined  to  be  acceptable. 

CONTEXT 

REQUIREMENTS 

4.2  VERIFICATION 
REQUIREMENTS 

4.3  VALIDATION 
REQUIREMENTS 

4.4  ACCEPTANCE 
REQUIREMENTS 

Process 

4.1 

OBSERVANCE 

REQUIREMENTS 

Data  on  the  performance  of  the  RAIN  system 
shall  be  collected  per  the  lower  lever 
requirements. 

4  QUALIFICATION 
REQUIREMENTS 

4.1.1  Verification  tests  by 
development  team 

4.1.2  Validation  tests  by  user 
representatives 

1  Perform  Rain  Integration 
Process 

4.1.1 

Verification  tests  by 
development  team 

The  system  verification  testing  shall  be 
conducted  by  members  of  the  system 
development  team 

4.1  OBSERVANCE 
REQUIREMENTS 

1  Perform  Rain  Integration 
Process 

4.1.2 

Validation  tests  by 
user  representatives 

The  system  validation  testing  shall  be 
conducted  by  PMA-263  user  representatives. 

4.1  OBSERVANCE 
REQUIREMENTS 

1  Perform  Rain  Integration 
Process 

4.2 

VERIFICATION 

REQUIREMENTS 

Verification  of  the  performance  of  the  RAIN 
system  shall  be  in  accordance  with  these  sub¬ 
requirements. 

4  QUALIFICATION 
REQUIREMENTS 

4.2.1  Verify  features  against 
req  doc 

1  Perform  Rain  Integration 
Process 

4.2.1 

Verify  features 

against  req  doc 

The  system  shall  be  verified  by  comparing  the 
system’s  features  against  this  requirements 
document. 

4.2  VERIFICATION 
REQUIREMENTS 

4. 2. 1.1  Verified  when  all 
requirements  are  met 

1  Perform  Rain  Integration 
Process 

4.2.1. 1 

Verified  when  all 
requirements  are 

met 

The  system  shall  be  verified  as  being  complete 
if  it  meets  all  the  requirements  listed  in  the 
operations  phase  of  this  requirements 
document. 

4.2.1  Verify  features 
against  req  doc 

1  Perform  Rain  Integration 
Process 

4.3 

VALIDATION 

REQUIREMENTS 

Validation  of  the  performance  of  the  RAIN 
system  shall  be  in  accordance  with  these  sub¬ 
requirements. 

4  QUALIFICATION 
REQUIREMENTS 

4.3.1  Validate  system 

functions  against  user  needs 

1  Perform  Rain  Integration 
Process 

4.3.1 

Validate  system 

functions  against 
user  needs 

The  system  shall  be  validated  as  being  correct 
by  operating  system  and  comparing  its  abilities 
against  what  the  user  needs. 

4.3  VALIDATION 
REQUIREMENTS 

4. 3. 1.1  Validated  when  all 
user  needs  are  met 

1  Perform  Rain  Integration 
Process 
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4.3. 1.1 

Validated  when  all 
user  needs  are  met 

The  system  shall  be  verified  as  being  complete 
if  it  meets  all  the  requirements  listed  in  the 
operations  phase  of  this  requirements 
document. 

4.3.1  Validate 

system  functions 

against  user  needs 

1  Perform  Rain  Integration 
Process 

4.4 

ACCEPTANCE 

REQUIREMENTS 

Acceptance  of  the  RAIN  system  shall  be  in 
accordance  with  the  lower  level  requirements. 

4  QUALIFICATION 
REQUIREMENTS 

4.4.1  Acceptable  if  validation 
indicates  needs  are  me 

1  Perform  Rain  Integration 
Process 

4.4.1 

Acceptable  if 

validation  indicates 
needs  are  me 

The  system  shall  be  considered  acceptable 
when  the  results  of  the  validation  testing 
indicate  all  user  needs  are  addressed. 

4.4  ACCEPTANCE 
REQUIREMENTS 

4.4. 1.1  Suggestions  for 

improvements  bound  needs 
will  be  remanded  for  future 
projects 

1  Perform  Rain  Integration 
Process 

4.4.1. 1 

Suggestions  for 

improvements 
bound  needs  will  be 
remanded  for  future 
projects 

Suggestions  for  improving  ease  of  use  or  speed 
of  use  of  the  system  shall  be  recorded  and 
remanded  for  future  projects. 

4.4.1  Acceptable  if 
validation  indicates 
needs  are  me 

1  Perform  Rain  Integration 
Process 
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APPENDIX  C.  ARCHITECTURE 


Component  Section 
IDEFO  Section 
FFBD  Section 
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COMPONENT  SECTION 


hier  Rain  Process 


1.X.1 
—  Safety 


Component 


1.X.2 


—  Security 
Component 


1.X.3 

Interoperability 


Component 


Compatibility 


Component 


Component 


Safety 


Component 


Security 

Component 


1.X.3 
—  Interoperability 


Component 


Compatibility 


Component 


Safety 


Component 


Security 

Component 


1.X.3 
Interoperability 


Component 


Compatibility 


Component 


Safety 


Component 


Security 

Component 


1.X.3 

Interoperability 


Component 


Compatibility 


Component 


1.1 

1.2 

[T3 

1.4 

1.5 

Certification 

Initiation 

Certification 

Collectors 

Analysis  Process 

Risk 

Package 

Developing 

Component 

Component 

Component 

Component 

Component 

Safety 


Component 


Security 

Component 


1.X.3 
—  Interoperability 


Component 


Compatibility 


Component 


Project: 


STUAS  Project 


Organization: 


Naval  Postgraduate  School  (N.P.S) 


July  20,  2013 
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RAIN  IDEFO  SECTION 


idefO  STUAS  System 


Naval  Postgraduate  School  (N.P.S) 
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idefO  Collect  Compatibility  Certification  Data 


Certification  Item  Approval 


Statutory/Regulatory  Requirements 


136 


137 


fO  Address  I  nteroperability  Certification  Ri: 


Interoperability 


STUA5  Project 


I  Organization: 

Naval  Postgraduate  School  (N.P.S) 


J  uly  20,  2013 


idefO  Address  Compatibility  Certification  Risk 


Developed  System  - 


Address 
Environmental 
Certifications  Risk 


►  Risk  Assessment 


Project: 

Organization: 

Date: 

STUAS  Project 

Naval  Postgraduate  School  (N.P.S) 

July  20,  2013 
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r 


jerability  Certification  Package  J 


I  nteroperability 


STUAS  Project 


I  Organization: 

Naval  Postgraduate  School  (N.P.S) 


I  Date: 


J  uly  20,  2013 


idefO  Develop  Compatibility  Certifications  Package 


7 


__  Assembled  Data  Package 


1. 5.4.1 _ 

Develop 

Environmental 

Certifications 

Pactoge 


►  Certification  Approval  Packages 

►  Final  System 


Develop  T&E 
Certifications 
Package 


Project: 

STUAS  Project 


I  Organization:  I  Date: 

|  Naval  Postgraduate  School  (N.P.S)  | 


July  20,  2013 


PMA-263/Developer 
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RAIN  FFBD  Decomposition  Section 


140 


ffbd  Determine  Safety  Certifications  J 


Project: 

STUAS  Project 

Organization: 

Naval  Postgraduate  School  (... 

Date: 

J  uly  20,  2013 

ffbd  Determine  Security  Certifications 


Project: 

Organization: 

Date: 

STUAS  Project 

Naval  Postgraduate  School  (. . . 

J  uly  20,  2013 

ffbd  Determine  Interoperability  Certifications 


Project: 

Organization: 

Date: 

STUAS  Project 

Naval  Postgraduate  School  (... 

July  20,  2013 
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ffbd  Collect  Security  Certification  Data 


Project: 

Organization: 

Date: 

STUAS  Project 

Naval  Postgraduate  School  (. . . 

J  uly  20,  2013 

ffbd  Collect  Interoperability  Certification  Data 


Project: 

Organization: 

Date: 

STUAS  Project 

Naval  Postgraduate  School  (... 

July  20,  2013 

ffbd  Collect  Compatibility  Certification  Data 


7 


1.2.2 

Perform 

Authority  Officer 
Certification  Col... 


1.2. 3. 4.1 
Collect 

Environmental 

Certifications 

Data 

Compatibility 


1.2. 3. 4.2 
Collect  T&E 
Certifications 
Data 

Compatibility 


Project: 

Organization: 

Date: 

STUAS  Project 

Naval  Postgraduate  School  (... 

J  uly  20,  2013 
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ffbd  Analyze  Safety  Certification  Data  " 


Project: 

STUAS  Project 

Organization: 

Naval  Postgraduate  School . . . 

Date: 

July  20,  2013 

144 


ffbd  Analyze  Interoperability  Certifications  Data  T 


Project: 

Organization: 

Date: 

STUAS  Project 

Naval  Postgraduate  School  (... 

July  20,  2013 

ffbd  Analyze  Compatibility  Certification  Data 


1.3.2.4.1 

Analyze 
Environmental 
Certifications 
Data 


T37l 

Compatibility 

1.3.3 

Specify  Data 

—►(and) 

(  and)— ► 

Address  Data 
Distribution 

Analysis  Process 

1.3.2. 4.2 

A 

Analysis  Process 

Certifications 

Data 


Compatibility 


Project: 


STUAS  Project 


Organization: 

Naval  Postgraduate  School  (... 


July  20,  2013 


ffbd  Address  Risk 


Project: 

Organization: 

Date: 

STUAS  Project 

Naval  Postgraduate  School  (... 

J  uly  20,  2013 
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ffbd  Address  Safety  Certifications  Risk 


1. 4.1.1 


Address 
Airworthiness 
Certifications  Risk 


Safety 


1.4.1. 2 


Address  Battery 
Certifications  Risk 


Safety 


1.4.1. 3 


Address  Laser 
Certifications  Risk 


Safety 


1.4.1. 4 

1.3 

1.5 

Analyze 

Certifications 

— ►(  and)— ► 

Address  Weapon 
Certifications  Risk 

— ►(and)— ► 

Develop 

Certification  Pa... 

Analysis  Process 

Package  Develo... 

Safety 

1.4.1. 5 


Address  System 
Safety 

Certifications  Risk 


Safety 


1.4.1. 6 


Address  Range 
Safety 

Certifications  Risk 


Safety 


1.4.1. 7 


Address  E3 
Certifications  Risk 


Safety 


Project: 

STUAS  Project 

Organization: 

Naval  Postgraduate  School  (. . . 

Date: 

July  20,  2013 

ffbd  Address  Security  Certifications  Risk 


1.4. 2.1 


Address  IA 
Certifications  Risk 


Security 


1.4. 2. 2 


Address 

>  Anti-Tamper 
Certifications  Risk 


1.3 

Security 

1 

r 

1.5 

Analyze 

Certifications 

— ►(  and) 

/  \ 

AND  ► 

Develop 

Certification  Pa... 

Analysis  Process 

(1.4.2. 3 

i 

k 

Package  Develo... 

Address  SAASM 
Certifications  Risk 


Security 


1.4. 2. 4 


Address 
Clinger-Cohen 
Act  Certifications 
Risk 


Security 


Project: 

STUAS  Project 

Organization: 

Naval  Postgraduate  School  (. . . 

Date: 

July  20,  2013 

ffbd  Address  Interoperability  Certification  Risk  T 


Project: 

STUAS  Project 

Organization: 

Naval  Postgraduate  School  (. . . 

Date: 

July  20,  2013 
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ffbd  Develop  Certification  Package 


Project: 

Organization: 

Date: 

STUAS  Project 

Naval  Postgraduate  School  (N.P.S) 

July  20,  2013 

ffbd  Develop  Security  Certifications  Package 


Project: 

Organization: 

Date: 

STUAS  Project 

Naval  Postgraduate  School  (N.P.S) 

July  20,  2013 

ffbd  Develop  Safety  Certification  Package 


Project: 

STUAS  Project 

Organization: 

Naval  Postgraduate  School  (N.P.S) 

Date: 

July  20,  2013 
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ffbd  Address  PMA-263  Activities 


Define  User 
Needs 


EXT.1.2 

>  Address  Requirements 
Requirement  Officer 


EXT. 1.3 


Develop  Payload 


Payload  Deve 


Provide  System  Integration 


System  Integration  Process 


Perform  Rain 
Integration  Pro.. 


Project: 

Organization: 

Date: 

STUAS  Project 

Naval  Postgraduate  School  (N.P.S) 

July  20,  2013 
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A  B 

CDEF  G  H  1  JK  LM 

Requirments 

Assigned  To 

In  Scope 

Requirements  Tracabilitg 

Testing 

Level  1 

Level  2 

(YfN) 

SfR 

Guiding  Instruction 

Sub  Instruction 

Approval  Authority 

Interim  Approval  (YfN) 

Waivable  (YfN) 

Waiver  Authority 

Documentation 

YfN 

CDL 

3 

Y 

S 

H.R.1815 

National  Defense 

Authorisation  Act  for 

Fiscal  Year  2006 

ASD  Memo 

Dec  30  2005 
Subject  DoD  CDL  Pilicy 

MDA 

N 

Y 

DoD  CIO 

Tech  data 

N 

Flight  Cert  (IFC) 

Peres 

Y 

S 

Title  49  USC,  Sec 
40103  -  Sovereignty 
and  use  of  airspace 

NAVAIRINST  13034.1D 

4.0P  -  Airworthiness 

Office 

N 

N 

NfA 

IFC 

N 

Risk  Assessment  Questionnaire 

RCC323 

HPOL 

HPOL 

EDRAP 

completed  data 
requirements  pkg 
spreadsheet 

LSRB 

laser  certification 

NOSSA 

battery  certification 

Risks 

SSRA  (System  Safety 
Risk  Assessment) 

E3 

(Electromagnetic 
Environmental  Effects) 

The  requirements  for  the  below  E3 
items  are  tailored  in  the  E3 
Integration  and  Analysis  Report. 

Ironhill 

Y 

SECNAVINST 

5000.2D, 

OPNAVINST 

2400.20F  St 

NAVAIRINST  2400.1 

MIL-STD-464C 

CNO  (N6) 

E3  Integration  and 
Analysis  Report 

N 

EMC  (Intra-system) 

Ironhill 

Y 

R 

MIL-STD-464C 

E3  Division  (AIR- 
4.1.131 

N 

Y 

CNO  (N6) 

E3  Verification 

Report 

Y 

EMI 

Ironhill 

Y 

R 

MIL-STD-464C 

MIL-STD-461F 

AIR-4.1.13 

N 

Y 

CNO  (N61 

E3  Verification 

Y 

EMP 

Ironhill 

Y 

R 

MIL-STD-464C 

AIR-4.1.13 

N 

Y 

CNO  (N61 

E3  Verification 

Y 

EMV  (Inter-system  EMC) 

Ironhill 

Y 

R 

MIL-STD-464C 

AIR-4.1.13 

N 

Y 

CNO  (N6) 

E3  Verification 

Y 

ESD 

Ironhill 

Y 

R 

MIL-STD-464C 

AIR-4.1.13 

N 

Y 

CNO  (N6) 

E3  Verification 

Y 

HERO  Testing 

Ironhill 

Y 

R 

MIL-STD-464C 

NAVAIR  16-1-529 

NOSSA 

N 

Y 

WSESRB  St  NOSSA 

E3  Verification 

Rpnnrr 

Y 

RADHAZ 

Ironhill 

Y 

R 

MIL-STD-464C 

AIR-4.1.13 

N 

Y 

CNO  (N6) 

RADHAZ  Analysis 
for  HERFfOfP 

N 

HERF  Analysis 

Ironhill 

Y 

R 

MIL-STD-464C 

Aircraft -AIR-4.1.13 
Ship  St  Shore  - 
NOSSA 

N 

Y 

CNO  (N6) 

E3  Verification 
Report 

N 

HERO  Analysis 

Ironhill 

Y 

R 

MIL-STD-464C 

NAVAIR  16-1-529 

NOSSA 

N 

Y 

WSESRB  St  NOSSA 

E3  Verification 

Rpnnrr 

Y 

HERP  Analysis 

Ironhill 

Y 

R 

MIL-STD-464C 

Aircraft -AIR-4.1.13 
Ship  St  Shore  - 
NOSSA 

N 

Y 

CNO  (N6) 

E3  Verification 
Report 

N 

Bonding  St  grounding  ??? 

Ironhill 

Y 

R 

MIL-STD-464C 

AIR-4.1.13 

N 

Y 

CNO  (N61 

E3  Verification 

Y 

Lightning 

Ironhill 

Y 

R 

MIL-STD-464C 

AIR-4.1.13 

N 

Y 

CNO  (N6) 

E3  Verification 

Y 

P-Static 

Ironhill 

Y 

R 

MIL-STD-464C 

AIR-4.1.13 

N 

Y 

CNO  (N6) 

E3  Verification 

N 

Environmental  Qualification 

MIL-STD-810G  tests  with  24  hour 
salt  fog,  Humidity,  Temp 

Lancaster 

Y 

S 

SECNAVINST  5000.2 

Corrosion  Control 

Plan  for  Air  Vehicle 

fPMA-263 

MIL-STD-810G 

AIR-4.3.4  Materials 
Division,  AIR-  4.3.4.6 
Corrosion  St  Wear 

N 

Y 

AIR  4.3.4 

Certified  Lab 
Report(s) 

Y 
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A _ 1 _ B _  C  ]  D  1  E  I _ F _ I _ G _ I _ H _ I _ I _ [  J  1 _ K _ [ _ L _ 1  M 


Requirments 

Assigned  To 

In  Scope 

Requirements  Tracabilitg 

Testing 

Level  1 

Level  2 

(YfN) 

SIR 

Guiding  Instruction 

Sub  Instruction 

Approval  Authority 

Interim  Approval  (YfN) 

Valuable  (Yf N) 

Vaiver  Authority 

Documentation 

YfN 

Disposal  Plan 

NA 

N 

NfA 

NfA 

N/A 

NfA 

NfA 

N/A 

NfA 

NfA 

0 

LSRB  Approval 

Otis 

Y 

S 

Title  21.  Code  of  Federal 
Regulations  (CFR),  Parts 
1040, 1040.10.  and  1040.11 

DoD  Instruction  6055.15 

LSRB 

Y 

N 

NA 

Laser  Certification 

Y 

Laser  radiation  hazard  evaluation 

R 

DoD  Instruction  6055.15 

OPNAVINST  5100.27B 

LSRB 

N 

N 

NA 

LASER  Characterization 
Test  Report  (ANSI  2136.4. 
Recommended  Practice  for 
Laser  Safety  Measurements 
for  Hazard  Evaluation) 

Y 

Laser  design  checklist 

R 

DoD  Instruction  6055.15 

OPNAVINST  5100.27B 

LSRB 

N 

N 

NA 

Design  Checklist  5100.27B 

N 

FDA  mil-exempt  letter 

R 

DoD  Instruction  6055.15 

Exemption  No.  76EL- 
01DOD.  Letter  of 
Exemption  from  the  Food 
and  Drug 

Administration  (FDA)  for 
DoD  Exemption  from 
Provisions  of  21  CFR 

m4fi 

LSRB 

N 

N 

NA 

Exemption  Leter 

N 

Battery  Approval 

Some  Li  batteries  do  not  require 
safety  (see  NAVSEA  S9310-AQ- 
SAF-010  for  details),  but  a  safety 
assessment  must  be  completed. 

The  NOSSA  Technical  Agent  will 
determine  the  level  of  9310  safety 
testing  required  based  on  the 
documentation  provided  with  the 
approval  request. 

Tran 

Y 

R 

NAVSEAINST  9310.1B 

All  sub  instruction  are 
contained  in  NAVSEA 
S9310-AQ-SAF-010 

NOSSAfNAVAIR 

4.4.5.2 

Y 

NO.  NOSSA  will 
not  issue  a 
waiver  for  9310 
safety 

requirements, 
but  may  issue  a 
interim  approval 
to  operate  the 
subject  battery 
for  a  limited 

amount  of  time. 

NOSSA  and  NAVAIR 
(4.4.5  2):  Although 
waivers  are  not 
granted,  an  interim 
approval  may  be 
granted,  but  the 
NOSSA  and  NAVAIR 

4.4.5.2  must  concur 

with  the  interim 
approval. 

Battery  certification 
Battery  exemption 

Y 

Product  spec  for  battery  cell 

battery  cell  drawinq 

Battery  schematic  (cell  &  control 
boardl 

battery  schematic  drawing 

CONOPS 

CONOPS 

Operator's  Manual 

payload  technical  manual 

Battery  safety  data  packaqe 

safety  data  packaqe 

Request  letter 

Request  letter  signed  by 
PMA 

IA  (Information  Assurance) 

Tran 

Y 

S 

DODD  8500.01E 

DODI  8500.2 

DODI  8510.01 

ODAA  (Operational 
Designated 
Accrediting  Authority) 

Y: 

IATT  (Interim  Authority 
to  Test) 

IATO  (Interim  Authority 
to  Operate) 

By  DAA  (Designated 
Accrediting  Authority) 

N 

NfA 

ATO 

Y 

SCG  (Security  Classification  Guide) 

SCG 

System  data 

-  Configuration  8c 
architecture  description 

-  Network  architecture 
diagram 

-  Ports  8c  protocols  list 

-  HWfSW  list 

-  vulnerabilities  scan 

CONOPS 

CONOPS 

AT  (Anti-Tamper) 

Tran 

Y 

S 

DODI  5000.2. 5200.39 

AT  Guidelines  Version  2 

ATEA 

Y 

N 

ATEA 

AT  Plan.  CPI  Assesment 

Y 
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A 

B 

D 

E 

F 

G 

H 

1 

J 

K 

L 

M 

Requiiments 

In  Scope 

- 

- 

Requirements  Tracability 

Testing 

2 

Level  1 

Level  2 

(YfN) 

SfR 

Guiding  Instruction 

Sub  Instruction 

Approval  Authority 

Interim  Approval  (YfN) 

Waivable  (YfN) 

Waiver  Authority 

Documentation 

YfN 

CCA  (Clinger-Cohen  Act) 

Y 

S 

DoDI  5000.2 

SECNAVINST  5000.2 

Cognizant  CIO 

N 

N 

NfA 

CCA  Comliance  Table 
populated  with  MDA 
specified  program  governing 
documentation  and  an 

N 

50 

51 

52 

Acquisition  Information 
Assurance  Strategy  (Note  1) 

53 

National 

T  elecommunications 

and  Information 

Administration 

JF-12 

Note  to  Holder  (NTH) 

N 

54 

Spectrum 

1.  Equipment  Spectrum  Certification 
(Frequency  Allocation)  1494  (SPS  & 
JF-12) 

Y 

S 

Title  47  US  Code  §305,  §901 
904 

47  CFR  300 

DoD  4650.01 

SECNAVINST  2400.1 

OPNAVINST  2400.20F 

NTIA  Spectrum 
Planning 
Subcommittee 

Y  -  with  submission  to 

SPS 

N 

NfA 

1494  in  EL-CID  Format 

M 

55 

2.  Assignments 

NTIA  Frequency 
Assignment 
Subcommittee 

Y-  Temporary 
Assignments  based  on 
SPS  submission  or  local 
NTIA  7.11  Authority 

Standard  Frequency  Action 
Format  (SFAF) 

N 

56 

System  Safety  Approval 

Y 

S 

MIL-STD  882 

DODI  5000.02 

NAVAIRINST  5100.11 

PMA 

N 

N 

NfA 

SSRA 

Y 

57 

Ranqe  Safety  Approval 

Y 

s 

DODD  3200.15 

OPNAVINST  3550.1A 

Ranqe  Safty  Officer 

N 

N 

NfA 

N 

58 

DT 

Y 

s 

DoD  Directive  5000.1, 
Defense  Acquisition 
Systems  (DAS) 

DoD  Instruction  5000.02, 
Operation  of  the  DAS 
CJCSI  3170.01,  Joint 
Capabilities  Intergration  & 
Development  System 
(JCIDS) 

Air  5.0 

Y 

Y 

PMA 

Y 

59 

T&E 

OT 

Y 

s 

SECNAVINST  5000.2, 
Department  of  the  Navy 
(DON)  Implementation  6c 
Operation  of  the  DAS  6c 
the  JCIDS 

NAVAIRINST  3960.2, 
Acquisition  Test  6c 
Evalustion 

VX-XX 

N 

N 

NfA 

TEMP 

Test  Plan 

Test  Supportability  Plan 
Test  Cards 

Test  Reports 

Y 

60 

WSESRB  Approval 

Y 

R 

NAVSEAINST  8020.6D 

Enclosure  (1) 
Membership, 
Responsibilities  and 
Procedures  of  the  Navy’s 
Weapon  System 
Explosives  Safety  Review 
Board 

Recommendations 
to  PM.  CNO,  and 
MDA  by  the 
WSESRB. 

N 

Y 

High  Risk  = 
ASN(RDA) 
Serious  Risk  =  PEO 

ModfLow  Risk  =  PM 

Entry:  Review  request  from 
PM  to  WSESRB  secretariat 

member.  Technical  data 
packages. 

Exit:  WSESRB  findings  f 
recommendations. 

N 

61 

JITC 

Y 

R 

DODD  4630.5 

DODI  4630.8 

DODI  5000.1 

DODI  5000.2 

CJCSI6212.01D 

CJCSI3170.01F 

CJCSM3710.01C 

J-6 

Y 

N 

NfA 

ICEPfITP 

DODAF  Views:  STV-1.SV-6 
or  OV-3,  SV-4,  SV-1, 8<  SV-2 
at  a  minimum. 

M 

64 

DoD  GPS  Security  Policy 
04  April  2006 

2007  CJCS  Master 
Positioning,  Navigation. 
And  Timing  Plan 
CJCSI  6130.01D 

13  ADril  2007 

N 

Y 

Y 

65 

Selective  Availability  Anti- 
Spoofing  Module  (SAASM) 

Security  Approval  for  SAASM  Host 
Application  Equipment  (HAE) 

Y 

R 

2007  CJCS  Master 
Positioning.  Navigation, 
And  Timing  Plan 
CJCSI  6130.01D 

13  ADril  2007 

GPU-09-105 

Security  Approval  Review 
Process  Reqt  Doc  for 
GPS  SAASM  HAE 

GPS  Directorate 
(GPSD) 

N 

N 

Assistant  Secretary 
of  Defense 

Tech  Data 

Y 

66 

SAASM  Design  Requirements  for 
HAE.  (SAASM  Functionalities, 
including  Extended  Functions) 

GPU-09-105 

Security  Approval  Review 
Process  Reqt  Doc  for 
GPS  SAASM  HAE 

ICD-GPS-227 

GPS  HAE  Design 
Requirements  with 
SAASM 

N 

N 

Y 
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A 

E 

N 

0 

P 

Q 

R 

S 

T 

U 

1 

Requirments 

Cost  (FY*K) 

Lead  Time  (Veeks) 

Duration  (Veeks) 

£ 

Level  1 

Level  2 

Low 

Med 

High 

Low 

Med 

High 

Low 

Med 

High 

3 

CDL 

$0.0 

$0.0 

$0.0 

0 

0 

0 

26 

52 

104 

4 

5 

Risk  Assessment  Questionnaire 

6 

HPOL 

7 

Flight  Cert  (IFC) 

EDRAP 

$0.0 

$0.0 

$0.0 

3 

8 

20 

2 

3 

4 

S 

LSRE 

3 

NOSSA 

10 

Risks 

15 

E3 

(Electromagnetic 
Environmental  Effects) 

The  requirements  for  the  below  E3 
items  are  tailored  in  the  E3 
Integration  and  Analysis  Report. 

$8.7 

$9.2 

$10.0 

0 

0 

0 

2 

2.18 

2.48 

16 

EMC  (Intra-system) 

$1.5 

$1.6 

$1.7 

0 

0.6 

1 

0.2 

0.218 

0.248 

17 

EMI 

$24.0 

$25.4 

$27.6 

0 

0.6 

1 

2 

2.18 

2.48 

13 

EMP 

$12.0 

$12.7 

$13.8 

0 

0.6 

1 

2 

2.18 

2.48 

19 

EMV  (Inter-system  EMC) 

$294.0 

r  $320.5 

r  $364.6 

1 

25 

52 

2 

2.5 

3 

20 

ESC 

$6.0 

$6.4 

$6.9 

0 

0.6 

1 

1 

1.09 

1.24 

21 

HERO  Testing 

$314.0 

r 

$342.3 

r 

$389.4 

1 

25 

52 

2 

2.5 

3 

22 

RADHAZ 

$2.7 

$2.9 

$3.1 

0 

0.6 

1 

0.4 

0.436 

0.496 

HERF  Analysis 

$6.0 

$6.4 

$6.9 

0 

0 

0 

1 

1.09 

1.24 

23 

24 

HERO  Analysis 

$6.0 

$6.4 

$6.9 

0 

0 

0 

1 

1.09 

1.24 

HERP  Analysis 

$6.0 

$6.4 

$6.9 

0 

0 

0 

1 

1.09 

1.24 

25 

26 

Bonding  &  grounding  22? 

$6.0 

$6.4 

$6.9 

0 

0.6 

1 

1 

1.09 

1.24 

27 

Lightning 

$80.0 

$84.8 

$92.0 

0 

0.6 

1 

2 

2.18 

2.48 

28 

P-Static 

$6.0 

$6.4 

$6.9 

0 

0.6 

1 

1 

1.09 

1.24 

Environmental  Qualification 

MIL-STD-810G  tests  with  24  hour 
salt  fog,  Humidity,  Temp 

$3.0 

$5.0 

$8.0 

1 

2 

4 

0.14 

0.42 

1 

29 
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A 

B 

M 

O 

P 

Q 

R 

S 

T 

U 

V 

1 

Ftequirments 

Cost  (FY*K) 

Lead  Time  (Veeks) 

Duration  (Veeks) 

£ 

Level  1 

Level  2 

Low 

Med 

High 

Low 

Med 

High 

Low 

Med 

High 

33 

Disposal  Plan 

0 

0 

0 

0 

0 

0 

0 

0 

0 

$0.0 

$0.0 

$0.0 

3 

5 

7 

0.2 

0.4 

2 

34 

Laser  radiation  hazard  evaluation 

$10.0 

$12.7 

$20.0 

3 

5 

7 

1 

2 

3 

35 

LSRE  Approve! 

36 

Laser  design  checklist 

$0.0 

$0.0 

$0.0 

2 

4 

8 

1 

2 

3 

FDA  mil-exempt  letter 

$0.0 

$0.0 

$0.0 

1 

3 

5 

0.2 

0.4 

1 

37 

38 

Battery  Approval 

Some  Li  batteries  do  not  require 
safety  (see  NAVSEA  S8310-AQ- 
SAF-010  for  details),  but  a  safety 
assessment  must  be  completed. 

The  NOSSA  Technical  Agent  will 
determine  the  level  of  8310  safety 
testing  required  based  on  the 
documentation  provided  with  the 
approval  request. 

$3.0 

$42.0 

$80.0 

0 

4 

8 

2 

14 

26 

38 

Product  spec  for  battery  cell 

40 

Battery  schematic  (cell  6:  control 
boardl 

41 

COMOPS 

42 

Operator's  Manual 

43 

Battery  safety  data  package 

44 

Request  letter 

45 

46 

SCG  (Security  Classification  Guide) 

IA  (Information  Assurance) 

System  data 

$0.0 

$0.0 

$0.0 

0 

24 

52 

1 

4 

4.1 

47 

48 

COMOPS 

48 

AT  (Anti-Tamper) 

□one  as  part  of  T&E.  Esp.  Evaluation. 
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1 

2 

Ftequirments 

Cost  (FY*K) 

Lead  Time  (Veeks) 

Duration  (Veeks) 

Level  1 

Level  2 

Low 

Med 

High 

Low 

Med 

High 

Low 

Med 

High 

50 

51 

52 

53 

CCA  (Clinger-Cohen  Act) 

$6.0 

$28.0 

$51.0 

5.4 

8 

11.4 

1 

2 

3 

Spectrum 

$0.0 

$0.0 

$0.0 

0 

0 

0 

0 

0 

0 

54 

1.  Equipment  Spectrum  Certification 
(Frequency  Allocation)  1484  (SPS  6: 
JF-12) 

$5.0 

$10.0 

$15.0 

4 

8 

12 

26 

38 

52 

55 

56 

57 

2.  Assignments 

$0.0 

$0.0 

$0.0 

4 

8 

12 

8 

18 

26 

System  Safety  Approval 

$3.0 

$25.0 

$50.0 

Shared  with  IFC  lead  time. 

0.1 

4 

26 

T&E 

Range  Safety  Approval 

$0.0 

$0.0 

$0.0 

1 

3 

4 

1 

3 

4 

58 

□T 

$100.0 

$200.0 

$800.0 

2 

5 

8 

1 

3 

12 

58 

60 

61 

□T 

$100.0 

$300.0 

$1,000.0 

20 

24 

32 

0.5 

1 

2 

VSESRB  Approval 

$1.5 

$2.0 

$3.0 

5 

8 

12 

0.1 

0.6 

1 

JITC 

$0.0 

$0.0 

$0.0 

4 

8 

12 

10 

12 

13 

64 

Selective  Availability  Anti- 
Spoofing  Module  (SAASM) 

0 

0 

0 

0 

0 

0 

0 

0 

0 

65 

Security  Approval  for  SAASM  Host 
Application  Equipment  (HAE) 

0 

0 

0 

0 

0 

0 

26 

52 

104 

66 

SAASM  Design  Requirements  for 
HAE.  (SAASM  Functionalities, 
including  Extended  Functions) 

$20.0 

$25.0 

$35.0 

4 

8 

12 

1 

1.5 

2.5 
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Requirmehts 

Cost  (FY$K) 

Cart 

LASER  Dai 

•tnator  Cart  Sim  lr>p< 

It 

P«riv»EW  Cart  Sim  Input* 

Aetiv*  EW  Cart  Sim  Input  j 

Level  1 

Level  2 

Low 

Med 

High 

C*K) 

RunlBL 

R1IRTR 

R1LRTR 

Run2BL  R2IRTR 

R2LRTR 

RunJBL 

R3IRTR  R3LRTR 

RunlBL  R1IRTR 

R1LRTR 

Run2BL  R2IRTR  R2LRTR 

RunJBL  RJIRTR 

RJLRTR 

RunlBL  R1IRTR  R1LRTR 

Run  2  BL  R2IRTR  R2LRTR 

Run3BL  R3IRTR 

R3LRTr| 

Flight  Cert  (IFC) 

EDRAP 

{0.0 

$0.0 

$0.0 

LSRB 

NOSSA 

Risks 

E3 

(Electromagnetic 
Environmental  Effect;) 

The  requirements  for  the  below  E3 
items  are  tailored  in  the  E3 
Integration  and  Analysis  Report. 

$8.7 

$3.2 

$10.0 

EMC  (Intra-system) 

$1.5 

$1.6 

$1.7 

EMI 

$24.0 

$25.4 

$27.6 

EMP 

$12.0 

$12.7 

$13.8 

EMV  (Inter-system  EMC) 

$234.0 

$320.5 

$364.6 

ESD 

$6.0 

r  $6.3 

HERO  Testing 

$314.0 

$342.3 

$383.4 

RA0HA2 

$2.7 

$2.3 

$3.1 

HERF  Analysis 

$6.0 

$6.4 

$6.3 

HERO  Analysis 

$6.0 

$6.4 

$6.3 

HERP  Analysis 

$6.0 

$6.4 

$6.3 

Bondinq  &  qroundinq  ??? 

$6.0 

$6.4 

$6.3 

Lightning 

$80.0 

$84.8 

$32.0 

P-Static 

$6.0 

$6.4 

$6.3 

Environmental  Qualification 

MIL-STD-810G  tests  with  24  hour 
salt  fog,  Humidity,  Temp 

$3.0 

$5.0 

$8.0 

MB* 

□ 

$0.0 

$0.0 

$0.0 

LSRB  Approval 

Laser  radiation  hazard  evaluation 

$10.0 

$12.7 

$20.0 

Laser  design  checklist 

$0.0 

$0.0 

$0.0 

FDA  mil-exempt  letter 

$0.0 

$0.0 

$0.0 

Some  Li  batteries  do  not  require 

0.5 

0.5 

Product  spec  for  battery  cell 

Battery  Approval 

Battery  schematic  (cell  &  control 
boardl 

$3.0 

$42.0 

CONOPS 

$80.0 

Operator's  Manual 

Battery  safety  data  packaqe 

Request  letter 

IA  (Information  Assurance) 

SCG  (Security  Classification 

$0.0 

$0.0 

$0.0 

System  data 

CONOPS 

AT  (Anti-T amper) 

Done  as  part  ofT&E. 

CCA  (Clinger-Cohen  Act) 

$6.0 

$23.0 

$51.0 

$0.0 

$0.0 

$0.0 

Spectrum 

1.  Equipment  Spectrum 
Certification  (Frequency 
Allocation)  1434  (SPS  &  JF-12) 

$5.0 

$10.0 

$15.0 

0.5 

0.25 

0.5  0.25 

0.5  0.25 

0.5  0.25 

2.  Assignments 

$0.0 

$0.0 

$0.0 

System  Safety  Approval 

$3.0 

$25.0 

$50.0 

Range  Safety  Approval 

$0.0 

$0.0 

$0.0 

T*E 

OT 

$100.0 

$200.0 

$800.0 

or 

$100.0 

$300.0 

##### 

0.5 

0.5 

0.5 

0.5 

0.5 

0.5 

0.5 

0.5 

■n 

0.5 

WSESRB  Approval 

$1.5 

$2.0 

$3.0 

4 

2 

2 

4  2  2 

JfTC 

$0.0 

$0.0 

$0.0 

0 

0 

0 

Selective  Availability  Anti- 
Spoofing  Module 

Security  Approval  for  SAASM 
Host  Application  Equipment 
(HAE) 

0 

0 

0 

(SAASM) 

SAASM  Design  Requirements  for 
HAE.  (SAASM  Functionalities, 
including  Extended  Functions) 

$20.0 

$25.0 

$35.0 

■ 

c 

■it  Sis. 

u«i»r 

uilti: 

0 

0 

• 

0  0  0 

0  0  0 

0  0  0 

0  0  0 

0  0  0 

0  0  0 

0  0  0 

0  0  0 
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APPENDIX  E.  OPERATIONAL  REQUIREMENTS  DOCUMENT 


RAIN  Operational  Requirements  Document 


Contents 

1  Inpul  Output  Requirements  for  Operations . 3 

1 . 1  Input  Requirements  for  Operations . 3 

1.1.1  Payload . 3 

1.1.2  Technical  Data  Package  (TDP) . 3 

1.1.3  Technical  Guidance  from  Certification  Authority . 3 

1.1.4  Payload  Returned  from  Testing . 3 

1.1.5  T&E  Summary . 4 

1.1.6  Packages  from  Technical  Certification  Authorities . 4 

1.1.7  System  Requirements . 4 

1.2  Output  Requirements  for  Operations . 4 

1.2.1  Fielding  decision  support  package . 4 

1.2.2  T&E . 4 

1.2.3  Design  Guidance . 4 

1 .2.4  Request  for  more  data  to  Developer . 5 

1.2.5  Certification  Approval  Request . 5 

1.3  External  Interface  Requirements  for  Operations . 5 

1.3.1  PMA-263 . 5 

1.3.2  T&E.. . 5 

1.3.3  Certification  Authorities . 5 

1.3.4  Developer . 5 

1 .4  Functional  Requirements  for  Operations . 5 

1.4.1  Payl  oad  Maturity . 5 

2  System-wide  /  Technology  Requirements  for  Operations . 7 

2. 1  Technology  Requirements  for  Operations . 7 

2.1.1  Documentation . 7 

2. 1 .2  Computer  Networks . 7 

2. 1 .3  Written  Communication . 7 

2.1.4  File  Sharing . 7 

2.2  Suitability  and  Quality  Requirements  for  Operations . 7 

2.2. 1  Complete  Fielding  Decision  Packages . 7 
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2.2.2  Accurate  Fielding  Decision  Packages . 7 

2.3  Cost  Requirements  for  Operations . 7 

2.4  Schedule  Requirements  for  Operations . 8 

3  Trade-off  Requirement  for  ( derations . 9 

3. 1  Performance  Trade-off  Requirements  for  Operations . 9 

3.1.1  Time  to  Address  Statutory  &  Regulatory  Requirement . 9 

3.1.2  Manage  Risks . 9 

3.2  Cost  Tradeoff  for  Operations . 1 0 

3.3  Cost-Performance  Trade-off  for  Operations . 10 

4  Qualification  Requirement  for  Operations . 1 1 

4. 1  Observance  Requirements  for  Operations . 1 1 

4.1.1  Verification  by  Development  Team . 1 1 

4. 1 .2  Validation  by  User  Reps . 1 1 

4.2  Verification  Plan  Requirements  for  Operations . 1 1 

4.2. 1  Verify  requirements  met  by  features . 1 1 

4.3  Validation  Plan  Requirements  for  Operations . 1 1 

4.3. 1  Validate  System  Operation  Meets  User  Needs . 1 1 

4.4  Acceptance  Plan  Requirements  for  Operations . 1 1 

4.4. 1  Acceptable  when  Validated . 1 1 

5  System  Improvement  /  Upgrade  Phase  Requirements . 12 

6  Retirement  Phase  Requirements . 12 

7  Overall  Trade-Off  Requirements . 1 2 

8  Appendix  A.  Operational  Concepts  by  Phase . 13 

9  Appendix  B.  External  Systems  Diagrams . 24 
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Blue  Highlights  need  to  be  confirmed  /  corrected. 

J|  are  tentatively  marked  for  deletion. 

Yellow  Highlights  indicate  missing  or  incomplete  sections. 

Pink  Highlights  are  the  same  as  yellow  but  different  to  stand  out. 


1  Input  /  Output  Requirements  for  Operations 

The  system  shall  input  and  output  all  data  required  in  this  section  to  support  integration 
and  fielding  of  payloads  on  STIJAS. 

1.1  Input  Requirements  for  Operations 

The  system  shall  input  all  data  required  in  this  sections  below  to  support  integration  and 
fielding  of  payloads  on  STUAS  at  the  Mission,  Stakeholder,  System,  Component,  and 
Configuration  levels. 


1.1.1  Payload 

The  system  shall  accept  the  payload  as  an  input. 

1.1.2  Technical  Data  Package  (TDP) 

'Hie  system  shall  input  Technical  Data  Packages  to  support  certification. 

1.1. 2.1  Design  Description 

The  system  input  the  payload  design  description. 

1 . 1 .2. 1 . 1  System  start  trigger 

Hie  system  shall  be  initiated  by  the  receipt  of  a  first  article  and  design  description 

1. 1.2.2  Payload  Data 

The  system  shall  collect  data  on  the  performance  of  the  payload. 

1 . 1 .2.2. 1  Data  for  each  type  of  certification 

The  system  shall  support  inputting  all  data  for  each  certification 

1.12.2. 1.1  Data  for  each  individual  certification 

'Hie  system  shall  input  all  data  for  each  certification  required  for  specific  payload 
integration  and  fielding  as  identified  by  the  certification  authority. 

1.1.3  Technical  Guidance  from  Certification  Authority 

The  system  shall  input  data  from  each  technical  certification  authority  to  identify  payload 
specific  data  and  certification  applicability. 

1.1.4  Payload  Returned  from  Testing 

'Hie  system  shall  collect  the  payload  after  T&E  is  completed. 
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1.1.5  T&E  Summary 

1. 1. 5. 1  Collection  of  Test  Reports 

1 . 1 . 5 . 1 . 1  Test  Reports  for  each  area 

The  system  shall  support  inputting  all  test  reports  for  each  certification 

1. 1.5.1. 1.1  Test  Report  for  each  cert  (as  applicable) 

The  system  shall  input  all  test  reports  for  each  certification  required  for  specific  payload 
integration  and  fielding  as  identified  by  the  certification  authority 

1.1.6  Packages  from  Technical  Certification  Authorities 

1. 1.6.1  Collection  of  certification  results 

The  system  shall  input  the  results  of  each  certification  request. 

1 . 1 .6. 1 . 1  Cert  results  for  each  area 

The  system  shall  input  overall  Safety.  Security,  Interoperability,  and  Compatibility. 

1. 1. 6. 1. 1. 1  Cert  results  for  each  type 

The  system  shall  input  all  certification  results  for  each  certification  required  for  specific 
payload  integration  and  fielding  as  identified  by  the  certification  authority 


1.1.7  System  Requirements 

The  system  shall  input  the  payload  mission  requirements. 

1.2  Output  Requirements  for  Operations 

The  system  shall  output  all  data  required  in  this  sections  below  to  support  integration  and 
fielding  of  payloads  on  STUAS  at  the  Mission,  Stakeholder,  System,  Component,  and 
Configuration  levels. 

1.2.1  Fielding  decision  support  package 

The  system  shall  provide  the  Program  Manager  with  a  fielding  options  decision  support 
package. 

1.2.2  T&E 

1.2.2. 1  T&E  Support  Request 

The  system  shall  output  a  T&E  support  request 

1. 2.2.2  Payload  to  T&E 

The  system  shall  provide  an  integrated  payload,  with  necessary  certification  to  support 

testing. 

/ .2.2.3  Direction  to  T&E 

The  system  shall  output  the  needed  testing  data  to  develop  test  plans. 

1.2.3  Design  Guidance 

The  system  shall  output  the  needed  design  changes  to  meet  certifications. 
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1.2.4  Request  for  more  data  to  Developer 

The  system  shall  output  requests  for  additional  data  needed  to  complete  certifications. 

1.2.5  Certification  Approval  Request 

The  system  shall  output  the  request  to  the  certification  approval  authority  when  all 
technical  data  has  been  provided. 

1.2.5. 1  Initial  Data  Package  for  certification 

'The  system  shall  output  data  packages  to  the  certification  approval  authority  for  initial 
certification  request. 

1.2. 5. 2  Updated  Data  Package  for  certification 

The  system  shall  output  data  packages  updates  to  the  certification  approval  authority  as 
required  and  upon  request. 


1.3  External  Interface  Requirements  for  Operations 

rfhc  system  shall  interface  with  all  external  entities  needed  for  payload  intergration, 
certification  and  fielding. 

1.3.1  PMA-263 

The  system  shall  interface  with  PMA-263  representatives. 

1.3.2  T&E 

The  system  shall  interface  with  T&E  representatives. 

1.3.3  Certification  Authorities 

The  system  shall  interface  with  all  representatives  required  for  system  certification. 

1.3. 3.1  PMA  Internal  Certification  SME’s 

The  system  shall  interface  with  NAVAIR  and  DoD  SMEs  as  need  for  certification. 

1.3.4  Developer 

The  system  shall  interface  with  payload  and  platform  developers. 

1.4  Functional  Requirements  for  Operations 

The  system  shall  support  the  payload  meeting  all  functional  requirements  outlined  below 
for  certification  and  operation. 

1.4.1  Payload  Maturity 

The  system  shall  provide  a  means  to  show  a  payload  is  ready  to  be  fielded. 

1.4. 1.1  Regulator y  and  Statutory  Compliance 

The  system  shall  provide  a  means  to  have  the  payload  comply  with  statutes  and 
regulations. 
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1 . 4. 1 . 1 . 1  Determine  Required  Certifications 


The  system  shall  provide  a  means  to  determine  the  certifications  needed  based  on  the 
capabilities  of  the  new  payload. 

1A.  1.  L  L 1  Certification  Tracking 

The  system  shall  provide  a  means  to  track  that  all  certifications  are  addressed 
1 . 4. 1 . 1 .2  Certification  Data  Collection 

The  system  shall  provide  a  means  to  collect  the  data  needed  to  suppoit  each  of  the 
required  certifications. 

1 .4.1 . 1  3  Certification  Data  Package  Evaluation 

The  system  shall  provide  a  means  to  evaluate  the  pre-submission  data  package  for 
each  technical  certification  for  adequacy, 

1.4.1. 1.4  Inlcrfa  ec  with  Ccr  till  cal  i  on  Aut  hor  it  i  cs 

The  system  shall  provide  the  means  of  interfacing  with  the  technical  certification 
authorities. 

1  A.  1.1 .4.1  Com  pi  l  an  ce  Pro  cess 

The  system  shall  provide  the  process  for  com  plying  with  the  guidance  from  the 
tech  n  teal  certifica  tion  a u  th  ori  ty. 

I  A.  1.2  Interoperability 

The  system  shall  provide  the  information  needed  to  prove  Interoperability. 

L4.L3  Safety 

The  system  shall  provide  the  information  needed  to  prove  Safety. 

I  AAA  Security 

The  system  shall  provide  the  information  needed  to  prove  Security. 

1A,L5  Suitability* 

The  system  shall  provide  the  information  needed  to  prove  Suitability. 

1A.1.6  En  vironmental  Compatibility 

The  system  shall  provide  the  information  needed  to  prove  Environ  mental  Compatibility. 
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2  System-wide  /  Technology  Requirements  for  Operations 

2.1  Technology  Requirements  for  Operations 

The  system  shall  be  constrained  by  the  following  technology  requirements. 

2.1.1  Documentation 

The  system  documentation  shall  be  limited  to  being  in  MS  Office  formats  (MS  Word 
2003,  MS  Excel  2003,  or  MS  Power  Point  2003  formats). 

2.1.2  C  omputer  Networks 

The  system  Computer  network  based  information  exchange  shall  operate  within  the 
limits  of  w  hat  the  NMCI  will  allow  or  support. 

2.1.3  Written  Communication 

Written  communication  of  the  system  information  shall  be  through  DoD  approved 
encrypted  e-Mai  1. 

2.1.4  File  Sharing 

File  sharing  shall  be  limited  to  PMA-263  and  DoD  approved  contractor  databases 


2.2  Suitability  and  Quality  Requirements  for  Operations 

The  system  shall  support  the  following  suitability  and  quality  requirements  for  operation. 

2.2.1  Complete  Fielding  Decision  Packages 

The  system  shall  produce  complete  fielding  decision  packages. 

2.2 . 1. 1  The  system  shall  address  all  relevant  statutes  and  regulations. 

2.2. 1.1.1  The  system  shall  provide  a  tailored  list  of  required  certifications  by  payload  system 
type. 

2.2. 1.1.2  The  system  shall  provide  the  Certifications,  approvals,  letter,  or  waiver  for  all  required 
statutes  and  regulations. 

2.2. 1. 1 .3  The  system  shall  provide  instructions  on  the  order  and  relative  start  times  for  each 
certification. 

2.2. 1.1.4  The  system  shall  provide  aggregated  risk  level  analysis  from  the  use  of  the  waiver  and 
interim  approvals. 

2.2. 1. 1.4. 1  The  system  shall  provide  instructions  on  the  risks  level  of  using  waivers  or  interim 
approvals. 

2.2. 1.2  The  system  shall  provide  the  justification  for  omitted  certifications  (statutes  and/or 
regulations  certifications). 

2.2.2  Accurate  Fielding  Decision  Packages 

The  system  shall  produce  complete  accurate  fielding  decision  packages. 

2.3  Cost  Requirements  for  Operations 
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The  system  shall  incur  the  same  or  lower  costs  as  the  current  processes  used  to  fully 
support  payload  fielding  decisions. 

2.4  Schedule  Requirements  for  Operations 

The  system  shall  provide  an  option  to  take  1 8  months  or  less  to  produce  the  fielding 
decision  package. 
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3  Trade-off*  Requirement  for  Operations 

The  below  fundamental  objectives  hierarchy  indicate  the  weighted  values  for  each 
bottom  level  objective  for  use  in  trading  off  features  used  during  operations,  but  implemented 


3.1  Performance  T rade-offf  Requirements  for  Operations 

The  system  shall  perform  a  trade-off  analysis  based  on  the  factors  identified  in  the 
systems  fundamental  objectives  hierarchy. 

3.1.1  Time  to  Address  Statutory  &  Regulatory  Requirement 

The  system  shall  minimize  time  to  address  statutory  and  regulatory  requirements  for 
fielding. 

3. 1. 1. 1  The  system  shall  minimize  time  to  determine  certifications  required  to  be  pursued 

3. 1. 1 . 1 . 1  The  system  shall  value  the  time  to  determine  needed  certifications  with  a  value  curve 
that  is  linear  with  a  value  of  1  at  one  day  or  less  and  zero  at  one  month. 

3. 7. 7. 7. 7. 7  The  system  shall  apply  a  trade  weight  of  15%  to  minimizing  the  time  to  determine 
required  certifications  when  de-conflicting  with  other  trade-off  requirements. 

3. 1. 1.2  The  system  shall  minimize  time  to  address  required  certifications. 

3. 1 . 1 .2. 1  The  system  shall  value  the  time  to  obtain  waivers  interim  approvals  with  a  value  curve 
that  is  linear  with  a  value  of  1  at  one  day  or  less  and  zero  at  six  months. 

3. 1. 1.2. 1. 1  The  system  shall  apply  a  trade  weight  of  35%  to  minimizing  the  time  to  obtain 
waivers/interim  approvals  when  de-conflicting  with  other  trade-off  requirements. 

3.1.1 .2.2  The  system  shall  value  the  time  to  obtain  full  certification  approvals  with  value  curve 
that  is  linear  with  a  value  of  1  at  one  day  or  less  and  zero  at  one  year. 

3. 1. 1.2.2. 1  The  system  shall  apply  a  trade  weight  of  35%  to  minimizing  the  time  to  obtain  full 
certification  approvals  when  de-conflicting  with  other  trade-off  requirements. 

3.1.2  Manage  Risks 

The  system  shall  provide  a  means  to  manage  risks. 

3. 1.2. 1  The  system  shall  minimize  waivers  and  interim  approvals. 

3. 1 .2. 1 . 1  The  system  shall  value  the  percentage  of  waivers/interims  with  a  value  cure  that  is 
linear  with  value  of  1  at  0%  and  0  at  100%. 
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3.12.1. 1.1  The  system  shall  apply  a  trade  weight  of  15%  to  minimizing  the  percentage  of 
waivers/interims  when  de-conflicting  with  other  trade-off  requirements. 


3.2  Cost  Tradeoff  for  Operations 

'Hie  first  phase  of  this  systems  development  shall  not  address  this  phase. 


3.3  Cost-Performance  T rade-off  for  Operations 

'Hie  first  phase  of  this  systems  development  shall  not  address  this  phase. 


10  of  25 


166 


4  Qualification  Requirement  for  Operations 

4.1  Observance  Requirements  for  Operations 

4.1.1  V erific  ation  by  Development  T earn 

The  system  verification  testing  shall  be  conducted  by  members  of  the  system 
development  team. 

4.1.2  Validation  by  User  Reps 

The  system  validation  testing  shall  be  conducted  by  PMA-263  user  representatives. 

4.2  Verification  Plan  Requirements  for  Operations 

4.2.1  Verify  requirements  met  by  features 

The  system  shall  be  verified  by  comparing  the  system  features  against  this  requirements 
document. 

4.2 . 1 . 1  The  system  shall  be  verified  as  being  complete  if  it  meets  all  the  requirements  listed  in 
the  operations  phase  of  this  requirements  document. 


4.3  Validation  Plan  Requirements  for  Operations 

4.3.1  Validate  System  Operation  Meets  User  Needs 

The  system  shall  be  validated  as  being  correct  by  operating  system  and  comparing  its 
abilities  against  what  the  user  needs. 

4.3. 1.1  The  system  shall  be  verified  as  being  complete  if  it  meets  all  the  requirements  listed  in 
the  operations  phase  of  this  requirements  document. 


4.4  Acceptance  Plan  Requirements  for  Operations 

4.4.1  Acceptable  when  Validated 

The  system  shall  be  considered  acceptable  when  the  results  of  the  validation  testing 
indicate  all  user  needs  are  addressed. 

4.4. 1.1  Suggestions  for  improving  ease  of  use  or  speed  of  use  of  the  system  shall  be  recorded 
and  remanded  for  future  projects. 
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5  System  Improvement  /  Upgrade  Phase  Requirements 

Hie  first  phase  of  this  systems  development  shall  not  address  this  phase. 


6  Retirement  Phase  Requirements 

The  first  phase  of  this  systems  development  shall  not  address  this  phase. 


7  Overall  Trade-Off  Requirements 

TTiis  section  is  to  address  comparisons  across  life-cycle  phases  in  order  to  enable 
coherent  evaluations  of  design  options. 

N/A,  the  non-opcrational  life-cycle  phases  are  being  conducted  by  Naval  Postgraduate 
School  students  as  part  of  their  Capstone  Project 
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8  Appendix  A*  Operational  Concepts  by  Phase 

A  text  table  format  is  used  to  describe  the  operational  concepts  and  scenarios  for  all  of 
the  life-cycle  phases.  For  the  operations  life -cycle  phase  sequence  diagrams  are  also  used. 

Operational  Concept  for  the  Development  Phase 


# 

Operational  Concept  Scenario 

Scenario  Type 

I 

The  development  phase  will  start  with  the  assignment  of 
the  team  members  to  a  pitched  project. 

*  System  initialization 

2 

The  team  will  work  together  to  research  and  draft  a 
project  management  plan  (PMP), 

*  Normal  steady  state 

3 

In  the  event  that  PMA-263  or  NPS  staff  or  other 
stakeholders  cannot  respond  quickly  the  team  will 
continue  with  development  under  the  assumption  that  the 
current  plan  is  correct  enough. 

*  Extremes  of  operations  due 
to  due  to  high  and  low  peaks 
of  the  external  systems  in 
each  standard  operating 
mode  in  each  context 

4 

N/A 

*  Standard  maintenance 
modes  of  the  system 

5 

N/A 

*  Standard  resupply  modes  of 
the  system 

6 

Lack  of  or  slow,  response  from  stakeholders  or  S MB’s 
in  PMA-263  will  be  addressed  by  our  team  members  in 
PMA-263  who  will  act  as  response  expatiators. 

*  Reaction  to  failure  modes  of 
other  systems 

7 

Missing  team  members  will  be  compensated  for  by 
having  more  than  one  team  member  up  to  speed  on  each 
task. 

*  Failure  modes  due  to 
internal  problems,  providing 
as  much  graceful 
degradation  of  the  meta- 
systeni  as  possible 

Operational  Concept  for  the  Production  Phase 
(Make  the  templates,  SEP,  checklists,  etc.) 


# 

Operational  Concept  Scenario 

Scenario  Type 

I 

System  design  will  commence  with  the  initial  prototype 
which  will  commence  upon  completion  of  requirements 
research. 

*  System  initialization 

2 

The  system  itself  will  he  designed  through  the  use  of 
evolutionary  prototyping,  where  models  are  used  to 
rcllnc  requirements  and  then  the  model  is  iteratively 
rellned  and  expanded  until  the  system  is  complete. 

*  Normal  steady  state 

3 

N/A 

*  Extremes  of  operations  due 
to  due  to  high  and  low  peaks 
of  the  external  systems  in 
each  standard  operating 
mode  in  each  context 
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4 

N/A 

•  Standard  maintenance 
modes  of  the  system 

5 

N/A 

•  Standard  resupply  modes  of 
the  system 

6 

Rejection  of  our  drafts  of  the  project  deliverables  will  be 
countered  with  additional  research  to  understand  where 
the  stakeholder’s  needs  were  not  addressed.  I,ack  of 
response  from  the  PM  A-263  will  be  addressed  by  our 
team  members  in  PMA-263  who  will  act  as  response 
expatiators.  Lack  of  response  from  NPS  will  be 
addressed  by  our  facility  advisors  who  will  act  as 
response  expatiators. 

•  Reaction  to  failure  modes  of 
other  systems 

7 

Disagreements  within  the  team  will  be  addressed  through 
the  use  of  consensus  building  discussions;  but  if 
consensus  cannot  be  achieved  then  multi-voting  will  be 
used  to  make  decisions  base  on  a  simple  majority. 

•  Failure  modes  due  to 
internal  problems,  providing 
as  much  graceful 
degradation  of  the  meta¬ 
system  as  possible 

Operational  Concept  for  the  Deployn 
(Install  /  Provide  to  the  Stakeho 

lent  Phase 

Iders) 

# 

Operational  Concept  Scenario 

Scenario  Type 

1 

Upon  completion  of  the  system  build  and  verification 
and  validation  testing  the  system  will  enter  the 
deployment  phase. 

•  System  initialization 

2 

Describe  how  the  deployment  of  the  new  the  system  will 
be  rolled  out  to  users  /  stakeholders.  The  documentation 
of  the  system  processes,  forms,  and  templates  will  be 
sent  to  Ops  for  proper  formatting  on  letterhead  and  then 
routed  lor  final  signature.  Ops  will  then  assign  a 
document  number  for  local  PMA-263  instructions.  CM 
will  then  log  it  accordingly.  The  document  will  then  be 
routed  to  the  IPTs  within  PMA-263. 

•  Normal  steady  state 

3 

N/A 

•  Extremes  of  operations  due 
to  due  to  high  and  low  peaks 
of  the  external  systems  in 
each  standard  operating 
mode  in  each  context 

4 

N/A 

•  Standard  maintenance 
modes  of  the  system 

5 

N/A 

•  Standard  resupply  modes  of 
the  system 

6 

N/A 

•  Reaction  to  failure  modes  of 
other  external  systems 

7 

Describe  how  we  will  address  not  being  ready  for 
deployment.  Deployment  will  be  delayed. 

•  failure  modes  due  to 
internal  problems,  providing 

14  of  25 


170 


Operational  Concept  for  the  Training  Phase 
(Train  the  users  on  how  to  use  the  tools  and  follow  the  process) 

This  is  outside  the  scope  of  the  project,  but  will  be  attempted  on  a  best  effort  if  time 

allows. 


# 

Operational  Concept  Scenario 

Scenario  Type 

1 

Describe  preparation  that  will  be  done.  Instructions  are 
sent  out  from  the  PMA. 

•  System  initialization 

2 

Describe  how  training  will  be  conducted.  Questions 
answered  as  they  come  up  and  directed  back  to  the  PMA. 

•  Normal  steady  state 

3 

N/A 

•  Extremes  of  operations  due 
to  due  to  high  and  low  peaks 
of  the  external  systems  in 
each  standard  operating 
mode  in  each  context 

4 

N/A 

•  Standard  maintenance 
modes  of  the  system 

5 

N/A 

•  Standard  resupply  modes  of 
the  system 

6 

N/A 

•  Reaction  to  failure  modes  of 
other  systems 

7 

n7a 

•  Failure  modes  due  to 
internal  problems,  providing 
as  much  graceful 
degradation  of  the  meta¬ 
system  as  possible 
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Operational  Concept  for  the  Operations  Phase 
(Tills  is  l  he  meat  of  the  new  process  and  life-cycle.  Not  sure  which  is  better  here  just  the 
text  table,  or  the  sequence  diagram,  or  both. ) 


ft 

Operational  Concept  Scenario 

Scenario  Type 

1 

A  payload  developer  delivers  a  new  payload  to  the  PM  A, 
the  developer  provides  data  results  from  the  tests  it 
conducted,  the  PM  A  analyzes  the  data  to  determine  if  the 
payload  meets  SWAP  requirements,  the  PM  A  analyzes 
the  data  to  determine  if  it  meets  the  iCl)  requirements  for 
the  intended  STUAS,  the  PM  A  conducts  a  fit  check  and 
operational  test  the  PM  A  initiates  the  integration  and 
fielding  process. 

♦  System  initialization 

2 

The  PM  A  collects  data  from  the  OEM,  the  PM  A 
develops  a  data  package  lor  each  technical  certification, 
NAVAIR  SME’s  review  the  data  packages,  the  SME’s 
determine  that  some  data  packages  are  sufficient  and 
others  are  not  sufficient,  the  sufficient  data  packages  are 
presented  to  their  approval  authorities  for  technical 
certifications,  additional  testing  is  scheduled  to 
supplement  the  data  in  the  insufficient  data  packages,  the 
additional  tests  arc  conducted,  the  insufficient  data 
packages  are  updated,  the  NAVAIR  SME’s  review  the 
data  packages,  the  SME’s  find  the  updated  data  packages 
to  be  sufficient,  the  updated  data  packages  are  presented 
to  their  approval  authorities  for  technical  certifications, 
the  data  packages  are  reviewed  by  the  approval  authority 
for  each  technical  certification,  the  approval  authority  for 
each  technical  certification  provides  approval  to  the 

PM  A,  the  PM  A  determines  that  all  certifications  have 
been  sufficiently  satisfied,  the  new  SoS  of  payload  and 
STIJAS  is  fielded  to  the  war  fighter. 

*  Normal  steady  state 

*  Assumptions: 

o  The  OEM  has  conducted 
some  of  the  needed  tests, 
o  The  Navy  needs  to 
conduct  additional  tests  in 
order  provide  all  the  data 
needed  to  support  all 
required  technical 
certifications. 

3 

The  PM  A  collects  data  from  the  OEM,  the  PM  A 
develops  a  data  package  for  each  technical  certification, 
NAVAIR  SME’s  review'  the  data  packages  the  SMF/s 
determine  the  data  packages  are  sufficient,  the  data 
packages  are  presented  to  the  approval  authority  for  each 
technical  certification,  the  data  package  is  reviewed  by 
the  approval  authority  for  each  technical  certification,  the 
approval  authority  for  each  technical  certification 
provides  approval  to  the  PM  A,  the  PM  A  determines  that 
all  certifications  have  been  sufficiently  satisfied,  the  new 
SoS  of  payload  and  STUAS  is  fielded  lo  the  war  fighter. 

*  Extremely  quick  operations 

•  Assumptions: 

o  The  OEM  has  conducted 
all  tests  needed  to  provide 
all  the  data  needed  to 
support  all  required 
technical  certifications. 

4 

The  PM  A  collects  data  from  the  OEM,  the  PM  A 
develops  a  data  package  lor  each  technical  certification, 
NAVAIR  SMK’s  review  the  data  packages,  the  SME/s 
determine  that  some  data  packages  are  sufficient  and 

*  Extremely  quick  operations 

*  Assumptions: 

o  The  OEM  has  conducted 
some  of  the  needed  tests. 
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others  are  not  sufficient  the  sufficient  data  packages  are 
presented  to  their  approval  authorities  for  technical 
certifications,  NAVAIR  submits  waiver  requests  for  the 
technical  certifications  with  insufficient  data  packages, 
the  data  packages  and  waiver  requests  arc  reviewed  by 
the  approval  authority  for  each  technical  certification,  the 
approval  authority  for  each  technical  certification 
provides  approval  to  the  PM  A,  the  PM  A  determines  that 
all  certifications  have  been  sufficiently  satisfied  or 
properly  waived,  the  new  SoS  of  payload  and  STUAS  is 
fielded  to  the  war  lighter. 

o  NAVAIR  has  some 
technical  certifications 
waived  instead  of 
conducting  additional 
tests. 

5 

The  PM  A  collects  data  irom  the  OEM,  the  PM  A 
develops  a  data  package  lor  each  technical  certification, 
NAVAIR  SMEJS  review  the  data  packages,  the  SMEJS 
determine  that  some  data  packages  are  sufficient  and 
others  are  not  sufficient  the  sufficient  data  packages  are 
presented  to  their  approval  authorities  for  technical 
certifications,  NAVAIR  submits  waiver  requests  for  the 
technical  certifications  with  insufficient  data  packages, 
the  data  packages  and  waiver  requests  are  reviewed  by 
the  approval  authority  for  each  technical  certification,  the 
approval  authority  for  one  or  more  of  the  waivers  rejects 
the  requests,  additional  testing  is  scheduled  to 
supplement  the  data  in  the  insufficient  data  packages,  the 
additional  tests  are  conducted,  the  insufficient  data 
packages  are  updated,  the  NAVAIR  SME’s  review  the 
data  packages,  the  SME’s  find  the  updated  data  packages 
to  be  sufficient,  the  updated  data  packages  arc  presented 
to  their  approval  authorities  for  technical  certifications, 
the  data  packages  arc  reviewed  by  the  approval  authority 
for  each  technical  certification,  the  approval  authority  for 
each  technical  certification  provides  approval  to  the 

PM  A,  the  PM  A  determines  that  all  certifications  have 
been  sufficiently  satisfied  or  properly  waived,  the  new 

SoS  of  payload  and  STUAS  is  fielded  to  the  war  fighter. 

*  Extremely  slow  operations 

*  Assumptions: 

o  The  OEM  has  conducted 
some  of  the  needed  tests, 
o  NAVAIR  seeks  but  is 
denied  waivers  on  some 
te  chti  i  cal  c  erti  fi  cati  oti  s. 

* 

6 

N/A 

*  Standard  maintenance 
modes  of  the  system 

7 

N/A 

*  Standard  resupply  modes  of 
the  system 

8 

A  failure  by  one  oft  he  technical  certification  approval 
authorities  to  render  a  verdict  will  be  followed  up  by  the 
PMA  until  a  the  issue  is  resolved  and  a  decision  is 
rendered. 

*  Reaction  to  failure  modes  of 
other  systems 

9 

The  PMA  collects  data  from  the  OEM,  the  PMA 
develops  a  data  package  for  each  technical  certification. 

*  Failure  leading  to  Extremely 
slow  operations 
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75 


Operations  -  Kxtremely  Quick  —  Missing  Data,  but  waived  the  certification 
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Operations  Extremely  Slow  Rad  Design  and  missing  data 
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9  Appendix  B.  External  Systems  Diagrams 
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APPENDIX  F.  MODELING  AND  SIMULATION 


RAIN  Simulation  Results 


Theoretical  upper  and  lower  bounds  on  completing  all  possible  certifications  for  a 
STUAS  payload 

•  Serial  Risk  Simulator®  and  iGrafx® 

•  Parallel  Risk  Simulator®  and  iGrafx® 

Baseline  Simulations 


•  LASER  Designator  Runs  1  though  3 

•  Passive  EW  Runs  1  though  3 

•  Active  EW  Runs  1  though  3 

Lead-time  Reduction  Simulations 


LASER  Designator  Timeline  Reductions  Runs  1  though  3 

•  Low  Risk  Timeline  Reduction  (LRTR) 

•  Intermediate  Risk  Timeline  Reduction  (IRTR) 

Passive  EW  Timeline  Reductions  Runs  1  though  3 

•  Low  Risk  Timeline  Reduction  (LRTR) 

•  Intermediate  Risk  Timeline  Reduction  (IRTR) 

Active  EW  Timeline  Reductions  Runs  1  though  3 

•  Low  Risk  Timeline  Reduction  (LRTR) 

•  Intermediate  Risk  Timeline  Reduction  (IRTR) 


Cost  Simulations 


LASER  Designator  Runs  1  though  3 

•  Baseline  (BL) 

•  Intermediate  Risk  Timeline  Reduction  (IRTR) 

•  Low  Risk  Timeline  Reduction  (LRTR) 

Passive  EW  Runs  1  though  3 

•  Baseline  (BL) 

•  Intermediate  Risk  Timeline  Reduction  (IRTR) 

•  Low  Risk  Timeline  Reduction  (LRTR) 

Active  EW  Runs  1  though  3 
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Baseline  (BL) 

Intermediate  Risk  Timeline  Reduction  (IRTR) 
Low  Risk  Timeline  Reduction  (LRTR) 


1st  Build  of  the  Simulation:  All  Certifications  in  Series 
Risk  Simulator® 

•  Triangular  distribution  for  each  certification  duration. 

•  34  Certifications 
Mean  =  469  weeks 

•  109.4  months 
80th  %  =  498  weeks 

•  116.2  months 

All  in  series  is  Very  Unlikely 
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1st  Build  of  the  Simulation:  All  Certifications  in  Series 
iGrafx®  Simulator 


Mean:  468  weeks 

•  109.2  months 
80th  %  =  495  weeks 

•  115.5  months 
Normal  Distribution 


Summary  for  CycleTIme  (Wits)  Certs  In  Series 
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*rd  -Quart  it 

m* ■! 

Mmmum 

£7143 

9S%  GmfkUnc*  Irattval  Flu  Matt 
*4  .IE  47a  A3 

95%  Cenfitkrcf-  Interval  h*  Median 
*4.14  4T123 

iE^t  Ctrfiterx*  ftwwJ  fa 
»JW  H-75 


Probability  Plot  of  CycleTime  (Wks)  Certs  In  Series 

Normal 
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2nd  Build  of  the  Simulation:  All  Certifications  in  Series 

Risk  Simulator® 

•  Triangular  distribution  for  each  certification  duration. 

•  34  Certifications. 

Mean  =  70  weeks 

•  16.2  months 
80th  %  =  84  weeks 

•  19.4  months 

All  in  Parallel  is  Very  Unlikely 
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2nd  Build  of  the  Simulation:  All  Certifications  in  Series 

iGrafx®  Simulator 


Mean:  70  weeks 

•  16.2  months 
80th  %  =  81  weeks 

•  18.7  months 

Non-Normal  Distribution  P<0.005 


Summary  for  CycleTinie  (Wks)  Certs 


in  Parallel 


1*1  ffJTOlj  iJdfl 

P  Vllllf  T  DiCflE 


ji^rl  Qtf-Jriie 

CanfidttUA  [nw+v  J  hr  Maai 
f-E:.t2D 


3S®  OariSicrice  farMed-io 

u.m  7D£*L 


LonfiJtnic  Cnlthvjh 

Mm-  | - * - t 

| - ■ - 1 

67  «  m  W  71 


ffiftCwtilBict  IrilinrdfcrStDur 
g-7L0 _ fc*Hl 


186 


Baseline  Simulations 


LASER  Designator  Runs  1  though  3 
Passive  EW  Runs  1  though  3 
Active  EW  Runs  1  though  3 


187 


LASER  Designator  Runs  1  through  3  Baseline 


LASER  Designator  Runs  1  through  3  Baseline 
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LASER  Designator  Run  Baseline  Model 


RAJN-Pi  owisii-Lase  i  -Run  1 J3-26-1 3-lirs.iqj; 


Elided  Time  in  Weeks 

[44266.10 1 


Activity  Statistics  In  WHis  {Hours} 


Count 

Avg  Cwle 

Avg  Seiv 

Awj  Bled 

Avg  VM 

SOD 

K853 

01  S3 

(inn 

ssfia 

Activity  Statistics  In  Weeks  (Hours) 


Grant 

Avg  Cyide 

Avg  Setv 

Avg  Rtock 

A/gWhik 

Wat  unMall  certs  srs  tone 

tm 

596 1 

M)67 

5967 

CHID 

DT 

500 

57.10 

57.10 

5170 

540 

FC  LcadTmc 

100C 

41.05 

41.05 

30  61 

10.44 

E3IAR  Update 

1000 

2m 

29.66 

27.45 

223 

Range  Safely  Lead  Tim 

500 

20.53 

28.56 

23.91 

2.07 

lASCCAhmsti  Ingelher 

500 

1843 

IK  43 

1843 

CHID 

Range  lately 

500 

20  m 

70  m 

LOOK 

708 

Fine h  Together 

500 

7.23 

7.23 

7.23 

0.00 

EMC  Lead  Time 

500 

0.54 

0.54 

000 

0.54 

LMI  Lead  lime 

500 

0.53 

0.53 

000 

0.53 

EMV  Lead  Tine 

500 

25.72 

25.72 

0.00 

25.72 

ESD  Lead  Time 

500 

0.50 

0.53 

000 

0.53 

ESD 

500 

111 

111 

000 

111 

Bonding  &  Grounding  Lead  Tim 

500 

0.52 

0.52 

0.00 

052 

Bondng  &  Grounding 

500 

111 

1.11 

0.00 

111 

LnvQuai  Lead  lime 

500 

2.31 

2.31 

000 

231 

Env  dual 

500 

0.53 

0.53 

000 

053 

LASS  LsidTifti 

IN 

m 

m 

m 

m 

LASS 

m 

m 

m 

m 

on 

lAHMA/hisI  laadtfna 

tfti 

m 

led 

dm 

4  BN 

LASHAZ  Eval 

1000 

1.99 

1.99 

000 
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LASER  Design  Chectiist  Lead  Tme 

500 

4.05 

4.85 

000 

405 

LASER  Design  ChetidisC 

1000 

2.06 

2.06 

000 

206 

! DA MIL-Liempt Letter  Leadline 

500 

‘m 

2.99 

0.00 

2.99 

FDA  MIL-Exempt  Letter 

1000 

0.53 

0.53 

0.00 

0.53 

Battery  Approval  Lead  Tine 

500 

3.96 

3.96 

000 

3.96 

Battery  Approval  Checklist 

1000 

14.26 

14.26 

000 

1123 

1A  Lead  Tine 

500 

25.71 

25.71 

0.00 

25.71 

1A  (iitertn) 

500 

3.02 

3.02 

0.00 

3.02 

CCA  Lead  Time 

500 

0.59 

8.59 

000 

659 

CCA 

500 

'.97 

1.97 

000 

1.97 

Sys  Safety 

500 

100? 

1007 

000 

100? 

PMA 

4000 

0.00 

0.00 

000 

0.00 

Start 

500 

0.00 

0.00 

000 

0.00 

OT 

500 

V 16 

1 18 

000 

1 16 

1  tmelfi  p  8  H.ilfl 

500 

0  (XI 

IHKt 

000 

008 

End 

500 

0.00 

0.00 

0.00 

0.00 

DT  Lead  Tine 

500 

4.96 

4.96 

000 

4.96 

rc 

500 

2.99 

2.99 

000 

299 

E31AR 

2500 

2.23 

2.23 

0.00 

223 

DT  lend  Time 

500 

?5?7 

7577 

000 

7527 

JTC  Lead  True 

500 

7.87 

7.87 

000 

7.37 

EMC  {htra-%s  EMC) 

500 

0.22 

0.22 

0.00 

022 

EMI 

500 

2.22 

2.22 

000 

222 

1  MV  (iitef-Sys  1  MG) 

500 

249 

249 

0111 

7  49 

JTC 

500 

11.66 

_JW 

1106 

LASER  Designator  Run  Baseline  Output  Data 


Summary  for  CycleTime  (Hrs)  Laser  Designator  Run  1 

ActivityName  =  End 


95%  Confidence  Intervals 


Anderaon-Darling  Normality  Test 

A-Sguared 

0M 

P-Value 

om 

Mean 

33.532 

St  Dev 

Variance 

146.361 

Skewneii 

0.206169 

Kurtoih 

-0.335918 

H 

500 

Minimum 

59213 

lit  Quart  tie 

79J14 

Median 

80 .050 

3rd  Quartile 

96.515 

Maiimum 

1264347 

95%  Confidence  Interval  For  Mean 

87.469 

09.595 

95%  Confidence  Interval  For  Median 

06.434 

89.315 

95%  Confidence  Interval  For  StDev 

11J92 

12.090 

Process  Capability  of  CycleTime 


Process  Date 

l£L 

0 

Target 

52 

USL 

73 

Sample  Mean 

83.5322 

Sample  N 

500 

StDev(JAiiiMn) 

12.3478 

StDev(Qveral|) 

12.088 

Within 
—  —  Overall 

Potential  flAAthin)  Capability 

Cp 

1.05 

CPL 

2.38 

CPU 

-0,28 

Qpk 

-0,28 

Overall  Capability 

107 

PPL 

2.44 

PPU 

43.28 

Ppk 

.0,28 

Cpm 

0,23 

Observed  Performance 
%<LSL  0.00 
%  >  USL  7020 
%  Total  7920 


Eip.  Within  Performance 
%<L5L  0.00 

%  >  USL  80.32 
%  Total  80,32 


Eip.  Overall  Performance 
%<LSL  0.00 
%>USL  80.00 
%  Total  80.80 


Probability  Plot  of  CycleTime  (Hrs)  Laser  Designator  Run  1 

Normal 


Mean 

33.53 

StDev 

12.10 

N 

BOO 

AD 

0.657 

P-Value 

0.006 
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LASER  Designator  Run  2  Baseline 
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RA  N  -Process-  La  ser-R  in2_G-Z7-1 3-hrs  J  g  x 


Elapsed  Time  in  Weeks 

43903.10  I 


Activity  Statistics  in  Weeks  (H  curs) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

500 

67.81 

87.81 

0.00 

87.81 

Activity  Statistics  in  Weeks  (Hours) 


Cnifit 

Ayg  Cycle 

Ayg  Serv 

Ayg  Block 

Ayg  Work 

Wait  until  all  certs  a  re  done. 

500 

56.94 

58.94 

58.94 

0.00 

DT 

500 

56.37 

56.37 

50.97 

5.40 

IFC  Lead  Time 

1000 

40.32 

40.32 

29.88 

10.44 

E3LAR  Update 

1000 

29.66 

29.66 

27.45 

2.23 

Range  Safety  Lead  Time 

500 

25.97 

25.97 

23.30 

2.67 

IAS  CCA  Finish  Together 

500 

18.43 

18.43 

18.43 

0.00 

Range  Safety 

500 

20.56 

20.56 

17.86 

2.66 

Finish  Together 

500 

7.23 

7.23 

7.23 

0.00 

EMC  Lead  Time 

500 

0.54 

0.54 

0.00 

0.54 

EMI  Lead  Time 

500 

0.53 

0.53 

0.00 

0.53 

EMV  Lead  Time 

500 

25.72 

25.72 

0.00 

25.72 

EnvQual  Lead  Time 

500 

2.31 

2.31 

0.00 

2.31 

EnvQual 

500 

0.53 

0.53 

0.00 

0.53 

LRSB  Lead  Tin* 

500 

5.02 

5.02 

0.00 

5.02 

LRSB 

1500 

0.39 

0.89 

0.00 

0.89 

LASHAZ  Eval  Lead  Time 

500 

4.98 

4.98 

0.00 

4.93 

LASHAZ  Eval 

1000 

1.99 

1.99 

0.00 

1.99 

LASER  Design  Checklist  Lead  Time 

500 

465 

4.65 

0.00 

4.65 

LASER  Design  Checklist 

1000 

2.08 

2.06 

0.00 

2.06 

Develop  &  Build 

500 

0.00 

0.00 

0.00 

0.00 

FDA  MIL-Exempl  Letter 

1000 

0.53 

0.53 

0.00 

0.53 

1A  Lead  Time 

500 

25.71 

25.71 

0.00 

25.71 

lA(hterim) 

500 

3.02 

3.02 

0.00 

3.02 

CCA  Lead  Time 

500 

8.59 

8.59 

0.00 

8.59 

CCA 

500 

1.97 

1.97 

0.00 

1.97 

Sys  Safety 

500 

1002 

10.02 

0.00 

10.02 

PMA 

3000 

0.00 

0.00 

0.00 

0.00 

Start 

500 

0.00 

0.00 

0.00 

0.00 

or 

500 

1.18 

118 

0.00 

1.13 

OT  Lead  Time 

500 

25.27 

26.27 

0.00 

25.27 

End 

500 

0.00 

0.00 

0.00 

0.00 

DT  Lead  Time 

500 

498 

4.98 

0.00 

4.98 

FC 

500 

2.99 

2.99 

0.00 

2.99 

E3IAR 

1500 

2.23 

223 

0.00 

223 

EMC  [Intra-Sys  EMC) 

500 

0.22 

0.22 

0.00 

0.22 

EMI 

500 

2.22 

2.22 

0.00 

2.22 

EMV  (hter-Sys  EMC) 

500 

249 

2.49 

0.00 

2.49 

FDA  MIL-Exempl  Letter  Lead  Time 

500 

2.99 

2.99 

0.00 

2.99 

Summary  for  CycleTime  (Hrs)  RAIN  Laser  Designator  Run  2 

Activity  Name  =  End 


95%  Confidence  Intervals 

M*r1-  | - * - 1 


WeJj'i  -i  | - • - 1 

*..0  36.5  a?ja  3/.5  33.0  31 39.0 


go  m  3G  u  un  lift  ua 


1  } 


Andereon-Dariing  Normality  Test 

A-Squared 

0.22 

P-Value 

0.041 

Mean 

07.0O6 

StDev 

12.952 

Variance 

167.754 

Skewness 

0.041971 

Kurtosis 

-0.3301O1 

N 

500 

Minimum 

55.704 

1st  Quartile 

70.560 

Median 

07.673 

3rd  Quartile 

96.515 

Maximum 

126.047 

95%  Confidence  Interval  For  Mean 

36.663 

00.944 

95%  Confidence  Interval  For  Median 

06.145 

09.1OO 

95%  Confidence  Interval  For  StDev 

12.196 

13.0O9 

Process  Capability  of  CycleTime 


H - 1 - 1 - 1 - 1 — **^~r'  1  |  1  1  i,i  1  1  |  1  1  i,i  1  1  1 1  1  1  11  m 

0.0  17,5  35.0  52.5  70.0  87,5  105.0  122.5 


Process  Data 

LB 

O 

Target 

52 

USL 

70 

Sample  Mean 

07.0O62 

Sample  N 

5O0 

StDev(Within) 

13.0913 

StDev(Overal[) 

12.952 

Potential  (Within)  Capability 

Cp 

* 

CPL 

* 

CPU 

-0.25 

Cpk 

-0.25 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

-0.25 

Ppk 

-0.25 

Cpm 

0.23 

Observed  Performance 

Exp.  Within  Performance 

Exp.  Overall  Performance 

PPM  <  LB 

0.00 

PPM  <  LB 

* 

PPM  <  LB 

* 

PPM  >  USL 

764000.00 

PPM  >  USL 

77309O.30 

PPM  >  USL 

775510.74 

PPM  Total 

764000.00 

PPM  Total 

77309O.30 

PPM  Total 

775510.74 

TW 


Probability  Plot  of  CycleTime  (Hrs)  RAIN  Laser  Designator  Run  2 

Normal 


Mean 

07,31 

StDev 

12.05 

H 

BOO 

AD 

0.210 

P-Value 

0.041 
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LASER  Designator  Run  3  Baseline 
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rain- Process-User- Run3  0-27-13  ivs  ^ 


Elapsed  Time  in  Weeks 


Activity  Statistics.  In  Weeks  [Hours) 


Counl 

Avg  Cyzte 

Avg  Serv 

Avg  Black 

Avg  Wort 

sna 

43.02 

ODD 

43.02 

Activity  Statistics  In  Weeks  [Hours) 


Court 

Avg  Cycle 

Avg  Serv 

Avg  Slock 

Avg  Work 

lA&CGAFinsh  Toctftiher 

5fl0 

18A3 

19.43 

15  43 

9  00 

Range  Safe  tv 

500 

20.56 

20.56 

17j6B 

2.66 

Wart  wni  all  cerls  are  done 

500 

15  15 

1513 

is  ia 

ODD 

Finish  Together 

500 

T  23 

7,23 

723 

ODD 

DcvckpS.  Bcpld 

500 

0.00 

0.00 

9.00 

9.00 

End 

500 

Li  00 

OOD 

ODD 

IFC 

500 

2.90 

900 

299 

IFC  Lead  Tint 

1000 

10.44 

990 

mwtii 

LR56  Le  nd  Time 

500 

5.02 

0.00 

LRSB 

500 

u.a& 

0.69 

0.00 

0.69 

LASER  Design  Checklist  Lead  Time 

500 

4.65 

4.05 

0.00 

4.05 

LASER  Design  Checklist 

1000 

2.06 

2.06 

0.00 

2.06 

IA  Lead!  Time 

500 

25.71 

25.71 

OOD 

33  71 

IA  (Interim) 

500 

0.02 

3.02 

0.90 

3.02 

CCA  Lead  Time 

500 

e.5& 

B.59 

0.00 

6.59 

CCA 

500 

1.97 

1.97 

990 

197 

Safety 

500 

10  02 

19.02 

090 

10  02 

PMA 

1500 

0.00 

0.00 

9.90 

0.00 

Start 

500 

0.00 

0.00 

0.00 

0.00 

or 

500 

1.13 

1  13 

OOD 

1  13 

OT  Lead  Time 

500 

4  97 

OOD 

4.97 

Harge  iiaSelv  Lead  Time 

500 

2.6? 

2.67 

OOD 

2.67 

1/1 
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Summary  for  CycleTime  (Hrs)  RAIN  LASER  Designator  Run  3 

ActivityName  =  End 


95%  Confidence  Intervals 


Andereon-Dariing  Normality  Test 

A-Squared 

1.47 

P-Value  < 

0.005 

Mean 

43.022 

StDev 

6.695 

Variance 

44.821 

Skewness 

0.331714 

Kurtosis 

-0.234230 

H 

500 

Minimum 

27.237 

1st  Quartile 

38.231 

Median 

42.162 

3rd  Quartile 

47.456 

Maximum 

65.057 

95%  Confidence  Interval  For  Mean 

42.434 

43.610 

95%  Confidence  Interval  For  Median 

41 .435 

43.174 

95%  Confidence  Interval  For  StDev 

6.304 

7.138 

31.5 


32  JG 


32.5 


33  JQ 


33.5 


Process  Capability  of  CycleTime  (Hrs)  RAIN  LASER  Designator  Run  3 


n - 1 - 1 - 1 —  ^  1  I  1  I  1  I  h  I  ^  I 

□  10  20  30  40  50  60  70 


Process  Data 

LB 

0 

Target 

52 

USL 

78 

Sample  Mean 

43.0221 

Sample  N 

500 

StDev(Within) 

6.74359 

StDev(Overal[) 

6.69484 

Potential  (Within)  Capability 

Cp 

* 

CPL 

* 

CPU 

1J3 

Cpk 

1J3 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

1.74 

Ppk 

1.74 

Cpm 

0.77 

Observed  Performance 

PPM  <  LB 

0.00 

PPM  >  USL 

0.00 

PPM  Total 

0.00 

Exp.  Within  Performance 
PPM  <  LB  * 
PPM  >  USL  0.11 
PPM  Total  0.11 


Exp.  Overall  Performance 

PPM  <  LB 

* 

PPM  >  USL 

0.09 

PPM  Total 

0.09 
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Probability  Plot  of  CycleTime  (Hrs)  RAIN  LASER  Designator  Run  3 

Normal 


Mean 

43.02 

StDev 

6.695 

N 

500 

AD 

1.467 

P-Value 

<0.005 
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Passive  EW  Runs  1  through  3  Baseline 
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Passive  EW  Run  1  Baseline 


RMKPaMEWAui  1.(27 13tiRKH 


Elapsvd  Turn  MwAs 


Transaction  Stafrsbcs  to  Weels  Hows) 


Oourt 

A#g  Cycle 

Aoj  Sea 

A#g  Block 

A<g  Wort 

5CC 

180  24 

180  24 

000 

180  24 

Aclvitf  Stalstics  to  Wteeks  Howsl 


Oounl 

AegQde 

AigSen 

AegBock 

A.gWoA 

ax 

1000 

5050 

5050 

000 

60  50 

SAASU  H»£ 

500 

5994 

5994 

000 

59  94 

intum  EgupSotannCtfl 

500 

3914 

39 14 

000 

3914 

life  l(«n«UMliw 

bM 

96  BD 

9680 

tub? 

55  99 

EMV  Lead  Time 

500 

2572 

2572 

000 

25  72 

1*  Lead  Time 

500 

4583 

4583 

2011 

25  71 

OT  Lead  Time 

500 

2527 

2527 

000 

2527 

Freq  AagmenE 

2000 

1790 

1790 

000 

17  90 

&aleey  Approval  Oeddf 

1000 

1428 

1428 

000 

14  28 

JTC 

500 

1166 

1166 

000 

1166 

IFC  Lead  Try* 

1000 

13275 

132  75 

12231 

10  44 

Sts  Saw 

500 

1002 

1002 

000 

10  82 

ri>  lead  lime 

bM 

?8/0 

78/0 

7011 

8  58 

IVSESRB  LeadTime 

750 

833 

833 

000 

133 

iVSESRBLeadTne 

750 

830 

830 

000 

130 

SAASM  Deugn  Reg  sit*  HIE  Lead  Time 

500 

104 

806 

000 

100 

II  HI  lelHepo* 

bM 

bid 

803 

DOO 

an 

iteqMigmnnh  lead  lime 

bM 

an 

8  03 

DM 

83.1 

Equip  Spectrum  Cert  Lead  Time 

500 

799 

799 

000 

799 

JTC  Lead  Time 

500 

787 

797 

000 

717 

OT 

500 

14811 

14811 

14340 

540 

D!  lead  Ire 

bOO 

4  98 

498 

DM 

4  98 

lialefy  Approval  l  e»a  line 

boo 

39B 

398 

DM 

3* 

14  frtenmj 

bOO 

3  OP 

» 

DM 

307 

IFC 

500 

299 

299 

000 

299 

Range  SJeh 

500 

2056 

2050 

17  88 

268 

l«i(>9e  sanely  lend  Time 

bOO 

109  bB 

109  bB 

1D691 

767 

ECHO  Tl«f>J 

500 

251 

251 

000 

251 

EMV  (Wl^lEMC) 

500 

4780 

4760 

4610 

249 

EnvQuil  Lead  Time 

502  281  231 

000  231 

E3IAR 

4000 

223 

223 

000 

223 

E3I4RU0UC 

10OQ 

12141 

12141 

11918 

223 

EMI 

500 

222 

222 

000 

222 

OCR 

bOO 

197 

197 

DM 

197 

S44SUDe*jn  Reqs1c*WE 

1000 

169 

169 

000 

169 

OT 

500 

111 

til 

000 

111 

Burning  I  Gipwtinq 

500 

111 

1.11 

000 

111 

l-CRP 

500 

111 

1.11 

000 

111 

lEftj 

500 

1.11 

111 

000 

111 

LSD 

500 

111 

1.11 

DOO 

111 

IE  HI 

bOO 

111 

111 

DM 

111 

IV3ESR6 

750 

0.57 

0.57 

000 

057 

WSESRB 

750 

056 

056 

000 

056 

R40H4Z  4njty»  Lead  Time 

500 

0.56 

055 

000 

055 

EMC  Lead  Time 

500 

7136 

7130 

7012 

054 

EMI  LeadTime 

500 

053 

053 

000 

053 

1  mi  Dual 

1000 

053 

053 

0M 

053 

FSD  lead  Time 

bOO 

053 

053 

0M 

053 

Editing  &  Grouting  LeadT.me 

500 

0.52 

052 

000 

052 

RACHAZAnMr» 

500 

044 

044 

000 

044 

EHCnntta-Sf  sEMCi 

500 

022 

022 

000 

022 

PM4 

3500 

000 

000 

000 

000 

St* 

500 

OOO 

OOO 

000 

000 

End 

bOO 

000 

OOO 

0M 

0M 

Wat  until  mi  cedsare  done 

bOO 

7623 

7673 

7673 

0M 

SAASM  MAE  LeadTne 

500 

000 

OOO 

000 

000 

Develop  8  Bold 

500 

000 

OOO 

000 

000 

Repeal’ 

500 

000 

OOO 

000 

000 

Repealed1 

750 

OOO 

OOO 

000 

000 

Repealed1  rt 

750 

OOO 

000 

000 

000 

Repeat1  wi 

500 

OOO 

000 

000 

000 

Coicainpie 

500 

073 

073 

073 

000 

niedifROKeuti 

bOO 

inn 

inn 

10303 

0M 

Doled  wsEsm  Rems 

bOO 

OOO 

OOO 

0M 

0M 

l4ICCAFir.fi  Together 

500 

1143 

1143 

1143 

000 

WSESRSOufc* 

500 

000 

OOO 

000 

000 

Fwifi  TpjeOet 

500 

723 

723' 

723 

000 
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Summary  for  CycleTime  (Hrs)  RAIN  Passive  EW  Run  1 

ActivityName  =  End 


135  1SQ  165  13Q  195  210  225  2*G 


# 


95%  Confidence  Intervals 


Anderson-Darling  Normality  Test 

A-Squared 

0.36 

P-Value 

0.438 

Mean 

130.24 

StDev 

15.35 

Variance 

251.15 

Skewness 

0.213344 

Kurtosis 

0.241126 

N 

500 

Minimum 

136.93 

1st  Quartile 

163.89 

Median 

130.67 

3rd  Quartile 

139.91 

Maximum 

241.25 

95%  Confidence  Interval  for  Mean 

178.35 

131.63 

95%  Confidence  Interval  for  Median 

173.37 

132.45 

95%  Confidence  Interval  for  StDev 

14.92 

16.90 
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Process  Capability  of  CycleTime  (Hrs)  RAIN  Passive  EW  Run  1 


Process  Data 

LB 

0 

Target 

52 

USL 

73 

Sample  Mean 

180.24 

Sample  N 

500 

StDev(Within) 

16.1491 

StDev(Overal[) 

15.8479 

Observed  Performance 

PPM  <  LB 

0.00 

PPM  >  USL 

1000000.00 

PPM  Total 

1000000.00 

0  35  70  105  140  175  210  245 


Exp.  Within  Performance 

PPM  <  LB 

* 

PPM  >  USL 

1000000.00 

PPM  Total 

1000000.00 

Exp.  Overall  Performance 

PPM  <  LB 

* 

PPM  >  USL 

1000000.00 

PPM  Total 

1000000.00 

- Within 

—  —  Overall 


Potential  (Within)  Capability 

Cp 

* 

CPL 

* 

CPU 

-2.11 

Cpk 

-2.11 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

-2.15 

Ppk 

-2.15 

Cpm 

0437 
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Probability  Plot  of  CycleTime  (Hrs)  RAIN  Passive  EW  Run  1 

Normal 


Mean 

180.2 

StDev 

15.85 

N 

500 

AD 

0.364 

P-Value 

0.438 
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Passive  EW  Run  2  Baseline 
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RA I  N-PassiveE  W-Ru  n-2_6-2  7-1 3-h  rs  .ig  x 


Elapsed  Time  in  Weeks 

43875.98 


Transaction  Statistics  In  Weeks  (Hours) 


Court 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

500 

87.75 

87.75 

0.00 

87.75 

Activity  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Wortt 

EMV  Lead  Time 

500 

25.72 

25.72 

0.00 

25.72 

IA  Lead  Time 

500 

25.71 

25.71 

0.00 

25.71 

OT  Lead  Time 

500 

25.27 

25.27 

0.00 

25.27 

IFC  Lead  Time 

1000 

40.26 

40.26 

29.83 

10.44 

Sys  Safety 

500 

10.02 

10.02 

0.00 

10.02 

CCA  Lead  Time 

500 

8.59 

8.59 

0.00 

8.59 

DT 

500 

56.32 

56.32 

50.92 

5.40 

DT  Lead  Time 

500 

4.96 

4.98 

0.00 

4.98 

IA  (Interim) 

500 

3.02 

3.02 

0.00 

3.02 

IFC 

500 

2.99 

2.99 

0.00 

2.99 

Range  Safety 

500 

20.56 

20.56 

17.88 

2.68 

Range  Safety  Lead  Time 

500 

2.67 

2.67 

0.00 

2.67 

EMV  (Interns  EMC) 

500 

2.49 

2.49 

0.00 

2.49 

EnvQual  Lead  Time 

500 

2.31 

2.31 

0.00 

2.31 

E3IAR 

1500 

2.23 

2.23 

0.00 

2.23 

E3IAR  Update 

1000 

29.68 

29.68 

27.45 

2.23 

EMI 

500 

2.22 

2.22 

0.00 

2.22 

CCA 

500 

1.97 

1.97 

0.00 

1.97 

OT 

500 

1.18 

1.18 

0.00 

1.18 

EMC  Lead  Time 

500 

0.54 

0.54 

0.00 

0.54 

EMI  Lead  Time 

500 

0.53 

0.53 

0.00 

0.53 

Erv  Qua! 

500 

0.53 

0.53 

0.00 

0.53 

EMC  (Intra-Sys  EMC) 

500 

022 

0.22 

0.00 

0.22 

Develop  &  Build 

500 

000 

0.00 

0.00 

0.00 

End 

500 

000 

0.00 

0.00 

0.00 

PMA 

2500 

0.00 

0.00 

0.00 

0.00 

Start 

500 

0.00 

0.00 

0.00 

0.00 

Wait  inti!  all  certs  are  done. 

500 

58.89 

58.89 

58.89 

0.00 

IA  &  CCA  Finish  Together 

500 

18.43 

18.43 

18.43 

0.00 

Finish  Together 

500 

7.23 

7.23 

7.23 

0.00 
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Summary  for  CycleTime(Hrs)  RAIN  Passive  EW  Run  2 

Activity  Name  =  End 


60 


ao 


90 


ioa 


no 


J20 


95%  ConFidence  Intervals 


Andereon-Dariing  Normality  Test 

A-Squared 

0.10 

P-Value 

0.914 

Mean 

07.752 

StDev 

13.041 

Variance 

170.055 

Skewness 

0.017197 

Kurtosis 

-0.300535 

N 

500 

Minimum 

54.079 

1st  Quartile 

70.476 

Median 

07.673 

3rd  Quartile 

96.515 

Maximum 

126.047 

95%  ConFidence  Interval  For  Mean 

S6.606 

00.090 

95%  Confidence  Interval  For  Median 

06.145 

09.100 

95%  ConFidence  Interval  For  StDev 

12.279 

13.903 

Process  Capability  of  CycleTime  (Hrs)  RAIN  Passive  EW  Run  2 


Process  Data 

LB 

0 

Target 

52 

USL 

70 

Sample  Mean 

07.752 

Sample  N 

500 

StDev(Within) 

13.1606 

StDev(Overal[) 

13.0405 

0.0  17.5  35.0  52.5  70.0  37.5  105.0  122.5 


- Within 

—  —  Overall 


Potential  (Within)  Capability 

Cp 

* 

CPL 

* 

CPU 

-0.25 

Cpk 

-0.25 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

-0.25 

Ppk 

-0.25 

Cpm 

0.23 

Observed  Performance 

PPM  <  LB 

0.00 

PPM  >  USL 

762000.00 

PPM  Total 

762000.00 

Exp.  Within  Performance 

PPM  <  LB 

* 

PPM  >  USL 

770515.33 

PPM  Total 

770515.33 

Exp.  Overall  Performance 

PPM  <  LB 

* 

PPM  >  USL 

772715.91 

PPM  Total 

772715.91 
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Probability  Plot  of  CycleTime  (Hrs)  RAIN  Passive  EW  Run  2 

Normal 


Mean 

37.75 

StDev 

13.04 

N 

500 

AD 

0.181 

P-Value 

0.014 
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Passive  EW  Run  3  Baseline 


v:  u  i. 


211 


RAIN-Pa  s-siweE  W-R  jn-3_S-Z7-1 3-hrs.  igx 


Elapsed  Time  in  Weeks 
17130  72 


Transaction  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

SCO 

34.20] 

34.26 

o.co] 

34.26 

Activity  Statistics  in  Weal 

;.s  |HoursJ 

Count 

Ayg  Cycle 

Avg  Serv 

Avg  Black 

Avg  Wark 

IA  Lead  Time 

500 

25.71 

25.71 

0.00 

25.71 

FC  LCAtnim* 

10W 

10.44 

10  44 

aw 

10.44 

Safety 

SW 

10  02 

10  02 

0,00 

1002 

CCA  Lead  Time 

500 

6.59 

0.59 

0.00 

6.59 

OT  Lead  Time 

SW 

4.97 

4.97 

o.w 

4.97 

IA  (Interim) 

500 

3.02 

3.02 

0.00 

3.02 

IFC 

5W 

2  99 

KD 

o.w 

2.99 

Range  Safety 

SW 

17,06 

2.0fi 

Range  Safety  Lead  Trti^ 

5W 

2  67 

2.67 

O.W 

2.67 

CCA 

5W 

1  97 

1  97 

O.W 

1.97 

OT 

SW 

1-lfl 

1.1* 

O.W 

l.lfi 

Develop  5  Build 

5W 

0  00 

O.W 

o.w 

O.W 

End 

500 

0.00 

0.00 

0.00 

0.00 

PMA 

sow 

000 

000 

o.w 

o.w 

5  lari 

1^^ 

0  00 

HO 

o.w 

Wall  until  an  ceds  are  dc^e. 

10  31 

o.w 

IA  &  CCA  Finish  Together 

SW 

1S43 

10  43 

16.43 

o.w 

Finish  Together 

SW 

7.23 

7.23 

7.23 

o.w 

1/1 
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Maid-i 


Summary  For  CycleTime  (Hrs)  RAIN  Active  EW  Run  3 


Activity  Name  =  End 


{ 


I 


95%  Confidence  Intervals 


\ - • - i 

l  ■  I 

55  Ss  S5- 


Anderson-Darling  Normality  Test 

A-5quaned 

1.15 

P-Vadue 

0,005 

Mean 

34.277 

StDev 

7.590 

Variance 

57.614 

Skewness 

0.237583 

Kurtosis 

-0.484966 

N 

500 

Minimum 

15.609 

1st  Quartile 

28J57 

Median 

33.614 

3rd  Quartile 

39.643 

Maximum 

54.400 

95%  Confidence  Internal  for  Mean 

33.511 

34.944 

95%  Confidence  Internal  for  Median 

32.863 

34.576 

95%  Confidence  Internal  for  StDev 

7.147 

8.092 

213 


Probability  Plot  of  CycleTime  (Hrs)  RAIN  Active  EW  Run  3 

Normal 


Mean 

34.28 

StDev 

7.590 

N 

500 

AD 

1.145 

P-Value 

0.005 

Process  Capability  of  CycleTime  (Hrs)  RAIN  Active  EW  Run  3 


Process  Data 

LB 

0 

Target 

52 

USL 

78 

Sample  Mean 

34.2774 

Sample  H 

500 

StDev(Within] 

7.57791 

StDev(OveralQ 

7.59036 

Observed  Performance 

PPM  <  LB 

0.00 

PPM  >  USL 

QrOQ 

PPM  Total 

Q.00 

Within 

Overall 


Potential  (Within)  Capability 

Cp 

* 

CPL 

+ 

CPU 

1.92 

Gpk 

1.92 

Overall  Capability 

Pp 

PPL 

* 

PPU 

1.92 

Ppk 

1.92 

Cpm 

0.45 

10  20  30  40  50  60  70 


Exp,  Within  Performance 
PPM  <  LB  * 
PPM  >  USL  0.00 
PPM  Total  0.00 


Exp.  Overall  Performance 
PPM  <  LB  * 
PPM  >  USL  0.00 
PPM  Total  0.00 


TPT 


Active  EW  Runs  1  through  3  Baseline 


AfiAi  y.v 

R.v  1  «; 

Tir.  >  li,jvylv.'i 

1-k'i  q  I'm  »-J h'kw  --r,1  ?A3'| 

OJL 

v 

EiC  .UHU.-ITI  ;-Ji:  ItlLl-l 

T 

Y 

14-tj 

W7TJ. 

Y 

Y 

ir-T-j- 

T 

Y 

Ik-tj 

ft! ret 

Y 

Y 

ZZVG. 

Y 

□k™ 

ftkT.  :-r«-VJ*TC 

Y 

Yw 

IAJ 

T 

Y 

ftk-P 

Yw 

EXi  r'  ,1s  s.-(.;.u-|fT  EUri 

Y 

Dwj 

ftSTi 

“kW 
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Active  EW  Run  1  Baseline 
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ra  i  r-j-A  ii  h.1  r  F1,*.'  -ra  i  n  -i_  n-y7-i  vnr?;  i  rp 


Clapsed  Time  in  Weeks 
|«ii?n  11 1 


Trpns acton  StittMics  In  Weeks  Warns) 


ftunil 

A.j  C.f  iJh 

Avg  Shv 

Avg  Rhi  lit 

AvgWuk 

em 

1B024 

18024 

000 

180.24 

.F,i:  t  v  !!r,i  !>u&£X'i  In  Waeks  lHamj 


Count 

AvgGfdlc 

AvgSt ti 

Ayg  Bled 

AvgWofc 

COL 

1D00 

3  D  .50 

00.50 

D.CO 

E0.5D 

SMSH  HAb 

bin 

EB.D4 

E0.O4 

0.00 

EU.94 

Irmim  Hqti®  SpedtruTi  G^ffl 

300 

M.H 

30.14 

0.00 

39.14 

hFRD  reingliudrifiE 

bin 

quo 

9ft  HI 

70  £7 

7b  M  ' 

EUV  Lead  Tune 

Em 

25.72 

2E.72 

D.CO 

25.72 

IA  Lead  Tiros 

500 

45.113 

4E.03 

20.11 

2571 1 

or  Lead  Time 

5D0 

2527 

2527 

0.00 

2  b.  27  | 

l-req  iagnnjnls 

im 

1/.D0 

lf.DO 

0.00 

17. HI 

Balery  Approval  Chectfii 

1D00 

1428 

14.2B 

D.CO 

14.26 

JTC 

bin 

ii.ee 

11.60 

0.00 

11.65 

IFG  L-Md  T  inw 

IDO* 

132.75 

1 32.75 

122.31 

1D.4i 

BjsSaHetr 

5  DO 

10.02 

10.02 

D.M 

10.02  | 

CCA  Lead  Time 

bin 

2£.70 

2070 

2IJ.11 

8.59  j 

AV3E  3RB  Lead  T  ime 

7M 

fi.33 

&33 

D.M 

8.33 1 

kYSFSRfl  1  EHdTirrp 

750 

8  30 

ft  30 

DM 

830 

SAASM  Dedgn  RK^rwHAE  LHd  Tine 

b(H 

£.06 

a  .36 

0.00 

8.06 

\zm  lEdn^it 

EDO 

0.0(3 

0.03 

D.M 

8.00 1 

Fi^Aajnribii'i  Lead  Time 

Em 

0.03 

&.05 

D.M 

8.03  j 

Equip  Spcdrum  Gcrl  Lead  Time 

E(H) 

7.33 

7.09 

D.M 

7.09 

JTC  Lead  Time 

Em 

7.87 

707 

D.M 

7.07 1 

rr 

bm 

'ill  81 

1 4ft  Ti  I 

14340 

540 

U\  Lead  Time 

Em 

4.03 

408 

D.M 

4.08 

Baterr  App^m'al  Lead.  Ti  me 

Em 

3.98 

308 

D.M 

3.0S 

IA  liilerimi 

bm 

3  OP 

30? 

DM 

3  0?  j 

IFG 

Em 

2.99 
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D.M 

2.09 

Ra  nqe  Safatr 

Em 

2056 

20.50 

i7.ua 

2.0S ' 

Kaigs  ilaleT.  Lead  tune 

Em 

10D.bE 

1D0.5U 

moi 

Z&7 1 

HERO  TBsins 

EDO 

251 

2.51 

D.M 

2  El 

EHVflrfartiriEUC) 

bm 

47  SO 

47  53 

45.10 

2  49 

EnvQUll  H«l  Tims 

&m 

2.31 

7.31 

D.M 

2.11 

□HR 

4  Dm 

2.23 

223 

D.M 

2.23 

E3SARU1  dale 

HUM 

121.41 

121.41 

119.18 

2.23 1 

FHI 

bm 

7?? 

77? 

nM 

7  7?  j 

CCA 

Em 

1.07 

107 

D.M 

197 1 

SAASM  Deacn  Re-q'srDr  HAE 

IDO* 

1.69 

109 

D.M 

1 C9 ' 

or 

bm 

1.18 

1.18 

0.00 

1.13 1 

Hording  A  Grounding 

Em 

1.11 

1  '1 

D.M 

1 11 

hERP 

Em 

1.11 

1.11 

D.M 

in 

hFRO 

bm 

1  11 

1  11 

DM 

1  91 

£50 

Em 

1.11 

1.11 

D.M 

1  11 

urt 

Em 

1.11 

1.11 

D.M 

1.11  | 

WSFRRR 

Tbfl 

057 

057 

DM 

Qb7| 

tVSfcHK ti 

7EO 

0.&6 

006 

D.M 

0.E6! 

FIACHAZ  Am4|rae  Lead  Time 

Em 

0.55 

055 

D.M 

0.56 1 

EU C Lead  Time 

Em 

7136 

71.30 

7012 

0.E4  j 

Fill  lead  Time 

bm 

053 

053 

DM 

0  53 1 

Lnv  Gual 

inm 

0.53 

053 

D.M 

0.53 

E3D  Lead  Tine 

Em 

0.53 

053 

D.M 

9  03 

Bonding  A  Ground  ng  Lead  Time 

bm 

0.S2 

0.52 

0.00 

0.52 

FftGHAZAiHtyas 

Em 

0.44 

0.44 

D.M 

0.44 

EMC  flnlra-SysEMC) 

Em 

022 

022 

D.M 

0.22 1 

PU  A 

ism 

OKI 

000 

DM 

om| 

sian 

Em 

0.00 

0  00 

D.M 

o.m| 

End 

Em 

0.00 

0.00 

D.M 

o.oo 

'm'hiI  Lidil  all  (Hlaaifl  lire 

bm 

7fl73 

7ft  73 

7ft  73 

om| 

saasm  HAb  Lead  rnn 

Em 

0.00 

0.00 

D.M 

o.rn 

Dcvel  Dp  £  Build 

Em 

0.00 

0.00 

D.M 

0.00 1 

Re  peat? 

Em 

D.M 

0.00 

D.M 

0.00 1 

RqpqatPd"'1 

7E0 

0.00 

000 

D.M 

0.00  i 

Fta  peated^  ■Aii 

m 

0.0-3 

0.00 

D.M 

O.OO  1 

Re  peat?  wl 

Em 

0.0-3 

0.00 

D.M 

O.OO  1 

mi  mi  iitpiti 

bm 

0  73 

073 

0  7.3 

amj 

Colec  TERO  Ftcodb 

Em 

103.0(3 

1D3.03 

103.03 

o.rn 

CdleaWSDERD  Resits 

Em 

D.CO 

0.00 

D.M 

o.oo  | 

lAiOCARnldi  Tegrttwf 

bm 

1£I3 

1143 

1343 

o.rn  | 

WS EERB  Outputs 

Em 

0.0-3 

0.00 

D.M 

o.rn 

fiJiidi  Tmjrther 

Em 

7.23 

723 

7.23 

o.oo  | 
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Mean 


Summary  for  Cycle!"  ime  (Hrs)  RAIN  Active  EW  Run  1 

Activity  Name  =  End  _ 


AnderttwvDaHing  Normality  Test 

A-Squarad 

0.35 

P-7alue 

0.433 

Mean 

m2* 

StDev 

i&.s& 

Variance 

251.15 

Skewness 

0.218344 

Kurtflsis 

0,241125 

N 

500 

Minimum 

13S,% 

1st  Qyartile 

Median 

m&7 

3rd  Qudrtle 

mm 

Marimum 

241-25 

85%  Confidence  Interval  for  Mean 

173.85 

181.63 

Confidence  Inteirval  for  Median 

173.37 

95%  Confidence  Interval  for  StDev 

14.32 

15.80 

^4^ 

A 

/ 

7~ 

/ 

H 

\ 

\ 

\ 

iis  m  ws  w 

195  210  H5  &Q 

*  - 1  1  1 -  *  * 

95*%  Confidence  Intervals 

i/a 


179 


1M 


131 


is 


Process  Capability  oF  CycleTime  (Hrs)  RAIN  Active  EW  Run  1 


0  35  70  105  140  175  210  245 


Process  Data 

m 

0 

Target 

52 

USL 

78 

Sample  Mean 

180.24 

Sample  N 

SOO 

StDev(WHthin) 

16.1491 

StDev(Overa!l) 

15 .8473 

Potential  (Within)  Capability 

cp 

CPL 

* 

CPU 

-Mi 

Cfrk 

-Ml 

Overall  Capability 

Pp 

PPL 

* 

PPU 

-2.15 

Ppk 

-2.15 

Cpm 

OJ07 

Observed  Petfiotmance 

PPM  <  LB 

O.OO 

PPM  >  USL 

1000000.00 

PPM  Tcrtal 

1000000.00 

Eip.  WUhin  Perfomfiarite 
PPM  <  IE  * 

PPM  >  USL  lOOCDDOJDO 
PPM  Tout  lQOOODOJDO 


Eip.  Overall  Petfown*nM 
PPM  <  IB  * 

PPM  >  USL  IOOCOPO.M 
PPM  Total  1000000.00 
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Probability  Plot  of  CycleTime  (Hrs)  RAIN  Active  EW  Run  1 

Normal 


1002 

is,es 

N 

sm 

AD 

0.564 

P-Walut 

0.433 
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Active  EW  Run  2  Baseline 


bi-uj.bC.  +r  , 
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RAIN-At  EiveE  W -R  un-2_6-27- 1 3-h  rs.  igx 


Elapsed  Time  in  Weeks 

1 66427.  B9 


Transaction  Statistics  In  Weeks  (H  ours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Bbck 

Avg  Work 

500 

152.6$ 

132.S6 

0.00 

132.86 

Activity  Statistics  In  Weeks  (Hours} 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

htnum  Equip  Spectrum  Gertt 

500 

39.14 

39.14 

0.00 

39.14 

EMV  Lead  Time 

500 

25.72 

25.72 

0.00 

25.72 

IA  Lead  Time 

500 

25.71 

25.71 

0.00 

25.71 

OTLead  Time 

500 

25.27 

25.27 

0.00 

25.27 

Freq  Assignments 

1500 

17.90 

17.90 

0.00 

17.90 

FC  Lead  Time 

1000 

35.37 

85.37 

74.93 

10.44 

Sys  Safety 

500 

10.02 

10.02 

0.00 

10.02 

CCA  Lead  Time 

500 

6.59 

a.59 

G.QQ 

a.59 

Freq  Assignments  Lead  Time 

500 

3.03 

3.03 

0.00 

8.03 

Equip  Spectrum  Cert  Lead  Time 

50D 

7.99 

7.99 

0.00 

7.99 

DT 

500 

101.42 

101.42 

96.02 

5.40 

DT  Lead  Time 

500 

4.98 

4.93 

0.00 

4.96 

IA  (Interim) 

500 

302 

3.02 

0.00 

3.02 

FC 

500 

2.99 

299 

G.QQ 

2.99 

Range  Safety 

500 

20.56 

20.56 

17.83 

2.68 

Range  Safely  Lead  Time 

50D 

2.67 

267 

0.00 

2.67 

EMV  (hter-Sys  EMC) 

500 

47.60 

47.60 

45.10 

2.49 

EnvQual  Lead  Time 

500 

2.31 

2.31 

0.00 

2.31 

E3IAR 

2000 

2.23 

223 

0.00 

223 

E31AR  Update 

1000 

72.79 

72.79 

70.56 

2.23 

EMI 

500 

2.22 

2.22 

0.00 

2.22 

CCA 

500 

197 

1.97 

0.00 

1.97 

OT 

500 

via 

1.16 

0.00 

1.13 

HERP 

500 

i.ii 

1.11 

0,00 

1.11 

HERO 

500 

1.11 

1.11 

0.00 

1.11 

HERF 

500 

in 

1.11 

0.00 

1.11 

RAD HAZ Analysis  Lead  Time 

500 

0.55 

0.55 

0.00 

0.55 

EMC  Lead  Time 

500 

71.36 

71.36 

70.82 

0.54 

EMI  Lead  Time 

500 

0.53 

0.53 

0.00 

0.53  ' 

Env  Qual 

500 

0.53 

0.53 

0.00 

0.53 

RADHAZAnatysis 

500 

0.44 

0.44 

0.00 

0.44 

EMC  (Inlra-Sys  EMC) 

50D 

D.22 

0.22 

0.00 

0.22 

Develop  S.  Build 

500 

0.00 

0.00 

0.00 

0.00 

End 

500 

0.00 

0.00 

0.00 

0.00  ' 

Wait  until  all  cede  are  done. 

500 

103.99 

103.99 

103.99 

0.00  ' 

PM  A 

3000 

0.00 

0.00 

0.00 

0.00 

Start 

500 

0.00 

0.00 

0.00 

0.00 

CollectHERQ  Results 

50D 

0.00 

0.00 

0.00 

0.00 

IAS  CCA  Finish  Together 

500 

16.43 

16.43 

18.43 

0.00 

Finish  Together 

500 

723 

723 

7.23 

0.00 

1/1 


221 


Meal 


Summary  for  CycleTime  (Hrs)  RAIN  Active  EW  Run  2 


ActivityName  =  End 


95%  Confidence  Intervals 


I - • - 1 

13L5  132.Q  IJS2.S  133.0  1333  IRQ 


Andereon-Dariing  Normality  Test 

A-Squared 

0.36 

P-Value 

0.436 

Mean 

132.36 

StDev 

10.02 

Variance 

100.40 

Skewness 

0.0650247 

Kurtosis 

0.0047435 

H 

500 

Minimum 

102.14 

1st  Quartile 

126.32 

Median 

132.61 

3rd  Quartile 

140.00 

Maximum 

163.39 

95%  Confidence  Interval  For  Mean 

131.97 

133.74 

95%  Confidence  Internal  For  Median 

131.49 

133.57 

95%  Confidence  Internal  For  StDev 

9.44 

10.69 

Process  Capability  of  CycleTime  (Hrs)  RAIN  Active  EW  Run  2 


LB  Target  USL 


Process  Data 

LB 

0 

Target 

52 

USL 

70 

Sample  Mean 

132.055 

Sample  H 

500 

StDev(Within) 

10.3060 

StDev(Overal[) 

10.024 

Within 
—  —  Overall 


Potential  (Within)  Capability 

Cp 

* 

CPL 

* 

CPU 

-1J7 

Cpk 

-L77 

Cverall  Capability 

Pp 

* 

PPL 

* 

PPU 

-1.02 

Ppk 

-1.02 

Cpm 

0.11 

Cbserved  Performance 

PPM  <  LB 

QrOO 

PPM  >  USL 

1000000.00 

PPM  Total 

1000000.00 

Exp.  Within  Performance 

PPM  <  LB 

* 

PPM  >  USL 

999999.95 

PPM  Total 

999999.95 

Exp.  Cverall  Performance 

PPM  <  LB 

* 

PPM  >  USL 

999999.90 

PPM  Total 

999999.90 

Probability  Plot  of  CycleTime  (Hrs)  RAIN  Active  EW  Run  2 

Normal 


i  1  t  1  i —  r  1  t  i  1  i  1  i 

100  110  120  130  140  150  160  170 

CycleTime 
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Active  EW  Run  3  Baseline 


e 


H 


fD- 

as  ip 

'■■UBI 
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RAIN-AcIweEW-Run  ■3_6-27-1ihra.igx 


tlapse^  Time  in  Weeks 
|  51217.77  | 


Tran  taction  StatiEtics  In  Weeks  (Hours) 


Couiil 

Ayg  Cycle 

Avg  -Scrv 

Avg  Slock 

A*g  Wprit 

SDQ 

102  44 

102.44 

Q  00 

102.44 

A::1i  tfiCy  Slatiilki  In  W r.ekz.  (HouA) 


Coum 

Avy  Cycle 

Ayg  Serv 

Avg  Work 

Annum  Equip  Spectrum  Qertt 

5CQ 

3314 

39  14 

0.00 

39.14 

1A  Lead  Time 

25 .71 

HO 

0.00 

25.71 

Freq  AiiKig  n  niEnls 

1790 

17.90 

0.00 

17.90 

IFC  LeadTme 

1&00 

10.44 

10.44 

0.00 

10.44 

5ys  Safely 

IS  02 

1002 

goo 

10  02 

CCA  Lead  Time 

500 

5.59 

6.59 

a.m 

6.50 

FrcqAMflw ments  Les^Trfie 

MC 

1.03 

n  oa 

o.« 

3  03 

zL|i.if:  SptfuU  ijiv  Ctfil  L«;jlI  Time 

500 

7.99 

7  99 

a.co 

7  99 

OT  Lead  Tima 

mo 

4.97 

o.cc 

4.97 

IA  (Intenm) 

KO 

3.02 

3.02 

o.cc 

■3 

IFC 

5W 

233 

2  93 

0.00 

2  99 

R?ri']+t  Safely 

500 

93  61 

93  61 

90  94 

2  66 

Ralye  Selely  Leta3  T me 

2.67 

mm 

O.Ofl 

2.67 

CCA 

MO 

1.97 

wmm 

0.00 

1.97 

OT 

MO 

1.18 

•mm 

0.00  | 

1  10 

Dmdtip  £  Build 

500 

o.oa 

O.DO 

a.oo 

Q.0D 

End 

0.00 

ODO 

a.oo 

POD 

PMA 

2D0Q 

o.aa 

O.DO 

a.oo 

DOD 

Stan 

mo 

0.00 

0.03 

O.Cfl 

0.00 

Wbh  ur*ti  all  certs  are  done. 

MO 

73  57 

73  57 

73.67  1 

0  00 

A  i  CCA  Finish  Tcyecher 

1645 

16.43 

D.0D 

Finish  Ttig«thrr 

7.23 

7  £3 

7.23 

POD 

1/1 
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Summary  for  CycleTime  (Hrs)  RAIN  Active  EW  Run  3 

ActivityName  =  End 


95%  Confidence  Intervals 

Mm  | - • - 1 

■'■fel.ji  -  | - • - 1 

1-30.L-  10 1.0  101.5  1-32  .-2  1-22.5  103.0  1-33.5 


Anderson-Darling  Normality  Test 

A-5quaned 

0.77 

P-Value 

0.046 

Mean 

102.44 

StDev 

9.56 

Variance 

91.49 

Skewness 

0.101192 

Kurtosis 

-0.010360 

N 

500 

Minimum 

73.96 

1st  Quartile 

95.73 

Median 

101.57 

3rd  Quartile 

109.20 

Maximum 

133.24 

95%  Confidence  Interval  For  Mean 

101.60 

103.20 

95%  Confidence  Interval  For  Median 

100.5S 

102.91 

95%  Confidence  Interval  For  StDev 

9.01 

10.20 

Process  Capability  of  CycleTime  (Hrs)  RAIN  Active  EW  Run  3 


LB  Target 


Process  Data 

LB 

0 

Target 

52 

USL 

70 

Sample  Mean 

102.436 

Sample  N 

500 

StDev(Within) 

9.07903 

StDev(Overalp 

9.56490 

I  1  I  1  I  1  1 

0.0  17.5  35.0  52.5 


Exp.  Within  Performance 

PPM  <  LB 

* 

PPM  >  USL 

993309.67 

PPM  Total 

993309.67 

Observed  Performance 

PPM  <  LB 

0.00 

PPM  >  USL 

992000.00 

PPM  Total 

992000.00 

Exp.  Overall  Performance 

PPM  <  LB 

* 

PPM  >  USL 

994605.05 

PPM  Total 

994605.05 

Within 
—  —  Overall 


Potential  (Within)  Capability 

Cp 

* 

CPL 

* 

CPU 

-0.02 

Cpk 

-0.02 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

-0.05 

Ppk 

-0.05 

Cpm 

0.17 

Probability  Plot  of  CycleTime  (Hrs)  RAIN  Active  EW  Run  3 

Normal 


Mean 

102.4 

StDev 

0.565 

N 

500 

AD 

0.763 

P-Value 

0.046 
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Lead-time  Reduction  Simulations 


LASER  Designator  Timeline  Reductions  Runs  1  through  3 

•  Intermediate  Risk  Timeline  Reduction  (IRTR) 

•  Low  Risk  Timeline  Reduction  (LRTR) 

Passive  EW  Timeline  Reductions 

•  Low  Risk  Timeline  Reduction  (LRTR)  Runs  1  though  3 

•  Intermediate  Risk  Timeline  Reduction  (IRTR)  Runs  1  though  3 

Active  EW  Timeline  Reductions 

•  Low  Risk  Timeline  Reduction  (LRTR)  Runs  1  though  3 

•  Intermediate  Risk  Timeline  Reduction  (IRTR)  Runs  1  though  3 
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LASER  Designator  Run  1 
Intermediate  Risk  Timeline  Reduction  (IRTR) 
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RAIN-Process-La  se  r-Ru  n  1  -IRT  R6-28-1 3-h  rs.  igx 


Elapsed  Time  in  Weeks 

I  25445.03  I 


Activity  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

500 

50.89 

50.89 

0.00 

50.89 

Activity  Statistics  in  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

DT 

500 

45.91 

45.91 

40.51 

5.40 

Wait  until  all  certs  are  done. 

500 

40.33 

40.33 

40.33 

0.00 

IFC  Lead  Time 

1000 

32.72 

32.72 

32.72 

0.00 

Range  Safety  Lead  Time 

500 

33.02 

33.02 

30.35 

2.67 

E3IAR  Update 

1000 

29.68 

29.68 

27.45 

2.23 

IA  &  CCA  Finish  Together 

500 

8.24 

8.24 

8.24 

0.00 

Finish  Together 

500 

8.08 

8.08 

8.08 

0.00 

Range  Safety 

500 

10.14 

10.14 

7.47 

2.68 

EMC  Lead  Time 

500 

0.54 

0.54 

0.00 

0.54 

EM  Lead  Time 

500 

0.53 

0.53 

0.00 

0.53 

EMV  Lead  Time 

500 

25.72 

25.72 

0.00 

25.72 

ESD  Lead  Time 

500 

0.53 

0.53 

0.00 

0.53 

ESD 

500 

1.11 

1.11 

0.00 

1.11 

Bonding  &  Grounding  Lead  Time 

500 

0.52 

0.52 

0.00 

0.52 

Bonding  &  Grounding 

500 

1.11 

1.11 

0.00 

1.11 

EnvQual  Lead  Time 

500 

2.31 

2.31 

0.00 

2.31 

Env  Qual 

500 

0.53 

0.53 

0.00 

0.53 

LRSB  Lead  Time 

500 

5.02 

5.02 

0.00 

5.02 

LRSB 

1500 

0.89 

0.89 

0.00 

0.89 

LASHAZEval  Lead  Time 

500 

4.98 

4.98 

0.00 

4.98 

LASHAZEval 

1000 

1.99 

1.99 

0.00 

1.99 

LASER  Design  Checklist  Lead  Time 

500 

4.65 

4.65 

0.00 

4.65 

LASER  Design  Checklist 

1000 

2.06 

2.06 

0.00 

2.06 

FDA  ML-Exempt  Letter  Lead  Time 

500 

2.99 

2.99 

0.00 

2.99 

FDA  ML-Exempt  Letter 

1000 

0.53 

0.53 

0.00 

0.53 

Battery  Approval  Lead  Time 

500 

0.00 

0.00 

0.00 

0.00 

Battery  Approval  Checklist 

1000 

2.37 

2.37 

0.00 

2.37 

IA  Lead  Time 

500 

0.00 

0.00 

0.00 

0.00 

IA  (Interim) 

500 

2.32 

2.32 

0.00 

2.32 

CCA  Lead  Tim  e 

500 

8.59 

8.59 

0.00 

8.59 

CCA 

500 

1.97 

1.97 

0.00 

1.97 

Sys  Safety 

500 

10.02 

10.02 

0.00 

10.02 

PMA 

4000 

0.00 

0.00 

0.00 

0.00 

Develop  &  Build 

500 

0.00 

0.00 

0.00 

0.00 

End 

500 

0.00 

0.00 

0.00 

0.00 

DT  Lead  Time 

500 

4.98 

4.98 

0.00 

4.98 

IFC 

500 

1.99 

1.99 

0.00 

1.99 

E3IAR 

2500 

2.23 

2.23 

0.00 

2.23 

Start 

500 

0.00 

0.00 

0.00 

0.00 

JITC  Lead  Time 

500 

0.00 

0.00 

0.00 

0.00 

EMC  (Intra-Sys  EMC) 

500 

0.22 

0.22 

0.00 

0.22 

EM 

500 

2.22 

2.22 

0.00 

2.22 

EMV  (Inter-Sys  EMC) 

500 

2.49 

2.49 

0.00 

2.49 

JITC 

500 

0.00 

0.00 

0.00 

0.00 

1/1 
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Summary  for  CycleTime  (Wks)  LASER  Designator  Run  1 IRTR 

ActivityName  =  End 


h - T 


95%  Confidence  Intervals 


49.0 


49.5 


50  JQ 


50.5 


510 


515 


520 


Andereon-DaHing  Normality  Test 

A-Squared 

0.36 

P-Value 

0.446 

Mean 

50.890 

StDev 

12.041 

Variance 

144.991 

Skewness 

0.094760 

Kurtosis 

-0.317885 

N 

500 

Minimum 

22.548 

1st  Quartile 

42.723 

Median 

50.694 

3rd  Quartile 

59.528 

Maximum 

84.568 

95%  Confidence  Interval  for  Mean 

49.832 

51.948 

95%  Confidence  Interval  for  Median 

49.169 

52.238 

95%  Confidence  Interval  for  StDev 

11.338 

12.838 

Process  Capability  of  CycleTime  (Wks)  LASER  Designator  Run  1  IRTR 


“  i  f  •  T  ‘  I  T  t  T  t  1 

0.0  12.5  25.0  37.5  50.0  62.5  75.0 


Process  Data 

LB 

to 

Target 

52 

USL 

78 

Sample  Mean 

50.8901 

Sample  N 

500 

StDevQWithin) 

11.7591 

StDev(Overal[) 

12.0412 

Potential  (Within)  Capability 

Cp 

CPI 

* 

CPU 

QJ7 

Cpk 

0J7 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

0.75 

Ppk 

0.75 

Cpm 

0J2 

Observed  Performance 

Exp.  Within  Performance 

Exp.  Overall  Performance 

%  <  LB 

0.00 

%  <  LB  * 

%  <  LB  * 

%  >  USL 

1.20 

%  >  USL  1.06 

%  >  USL  1.22 

%  Total 

120 

%  Total  1.06 

%  Total  122 

UT 


Probability  Plot  of  CycleTime  (Wks)  LASER  Designator  Run  1 IRTR 

Normal 
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LASER  Designator  Run  1 
Low  Risk  Timeline  Reduction  (LRTR) 


T  -mull 
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RAIN-Process-Laser-RLrMRTR_6-28-B-hrs.ig)( 


Elapsed  Time  in  Weeks 
2591669  | 


Activity  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

AvgServ 

Avg  Block 

Avg  Work 

500 

51.83 

5183 

000 

51  83 

Activity  Statistics  in  Weeks  (Hours) 


| 

Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

|  DT 

500 

46.35 

4635 

40  96 

5.40 

IFC  Lead  The 

1000 

30.32 

30.32 

30.32 

0.00 

E31AR  Update 

1000 

29.68 

29.68 

27.45 

2.23 

Wait  until  all  certs  are  done 

500 

2348 

23.48 

23  48 

000 

Range  Safety  Lead  The 

500 

25.97 

25.97 

23.30 

2.67 

A  &  CCA  Finish  Together 

500 

18.43 

18.43 

18.43 

0.00 

Finish  Together 

500 

8.08 

8.08 

8.08 

0.00 

Range  Safety 

500 

10.58 

10  58  ] 

790 

2.68 

EMC  Lead  The 

500 

0.54 

0.54 

0.00 

0.54 

EM  Lead  The 

500 

0.53 

0.53 

0.00 

0.53 

EM7  Lead  Time 

500 

25.72  | 

25.72 

0.00 

25.72 

ESD  Lead  Time 

500 

0.53 

0.53 

000 

0.53 

ESD 

500 

t.ii 

1.11 

0.00 

1.11 

Bonding  &  Grouping  Lead  The 

500 

0.52 

0.52  r 

0.00 

0.52 

Bonding  &  Groinding 

500 

1.11  | 

1.11 

000 

1.11 

EnvQual  Lead  Time 

600 

2.31 

2.31 

0.00 

2.31 

EnvQuil 

500 

0.53 

0.53 

ooo 

0.63 

LRSB  Lead  Time 

500 

5.02 

5  02 

000 

5.02 

LRSB 

1500 

0.89 

0.89  1 

0.00 

0.89 

LASHAZEval  Lead  Tme 

500 

4.98  j 

4  98  J 

ooo 

498 

LASHAZEval 

1000 

1  99  | 

1.99 

0.00 

1.99 

LASER  Design  Checklist  Lead  Time 

500 

4.65 

4.65 

0.00 

4.65 

LASER  Design  Checklist 

1000 

2.06’ 

2.06 

0.00 

2.06 

F  DA  ML-  Exem  pt  Letter  Lead  Tim  e 

500 

299 

299 

0.00 

2.99 

FDA  ML-Exempt  Letter 

1000 

0.53  j 

0  53  ’ 

ooo 

0.53 

A  Lead  Time 

500 

25.71  1 

25.71 

0.00 

25.71 

A  (Interim) 

500 

3  02 

3.02 

ooo 

3.02 

CCA  Lead  Time 

500 

8.59 

8.59 

0.00 

8.59 

CCA 

500 

1  97 

1.97 

ooo 

197 

Sys  Safety 

500 

10.02 

10.02 

0.00 

10.02 

PMA 

3500 

0.00 

000 

ooo 

0.00 

Develop  &  Buid 

500 

0.00 

000 

ooo 

000 

End 

500 

0.00  ! 

000 

ooo 

000 

DT  Lead  Time 

500 

4.98 

4.98 

0.00 

4.98 

IFC 

500 

1.99 

1.99 

0.00 

1.99 

E3AR 

2500 

2.23 

2  23 

0.00 

2.23 

Start 

500 

0.00 

0.00 

0.00 

0.00 

JITC  Lead  Time 

500 

7.87 

7.87 

0.00 

7.87 

EMC  (Intra-Sys  EMC) 

500 

0.22 

0.22 

0.00 

0.22 

EM 

500 

2.22 

2.22 

ooo 

2.22 

EIW  (inter-Sys  EMC) 

500 

2.49  J 

2.49 

0.00 

2.49 

JITC 

500 

11.66 

11.66 

0.00 

11.66 

1/1 
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Summary  for  CycleTime  (Wks)  LASER  Designator  Run  1  LRTR 

Activity  Name  =  End 


95%  Confidence  Intervals 


Andereon-DaHing  Normality  Test 

A-Squared 

120 

P-Value  ■=: 

0.005 

Mean 

51.033 

StDev 

10.944 

Variance 

119.775 

Skewness 

0.320759 

Kurtosis 

-0.259609 

N 

500 

Minimum 

26.670 

1st  Quartile 

43.503 

Median 

50.904 

3rd  Quartile 

59.520 

Maximum 

04.560 

95%  Confidence  Interval  For  Mean 

50.072 

52.795 

95%  Confidence  Interval  For  Median 

49.030 

52.339 

95%  Confidence  Interval  For  StDev 

10.305 

11.660 

Process  Capability  of  CycleTime  (Wks)  LASER  Designator  Run  1  LRTR 


Process  Data 

LB 

0 

Target 

52 

USL 

70 

Sample  Mean 

51.0334 

Sample  N 

500 

StDev(Within) 

10.9212 

StDev(Overal[) 

10.9442 

Observed  Performance 
%  <  LB  0.00 
%  >  USL  120 
%  Total  120 


I  ^  i 1 

0.0  12.5  25.0  37.5  50.0  62.5  75.0 


Exp.  Within  Petfotmance 
%  <  LB  * 

%  > USL  0.33 
%  Total  0.33 


Exp.  Overall  Performance 
%  <  LB  * 

%  >  USL  0.@4 
%  Total  0.04 


■  Within 
Overall 


Potential  (Within)  Capability 

Cp 

* 

CPL 

+ 

CPU 

0,30 

Cpk 

0,30 

Overall  Capability 

Pp 

+ 

PPL 

* 

PPU 

0.00 

Ppk 

0,00 

Cpm 

OJ9 
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Probability  Plot  of  CycleTime  (Wks)  LASER  Designator  Run  1  LRTR 

Normal 


Mean 

51.33 

StDev 

10.04 

N 

50O 

AD 

1.202 

P-Value 

<0.005 
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LASER  Designator  Run  2 
Intermediate  Risk  Timeline  Reduction  (IRTR) 
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RA I N-P  rocess-Laser-  Ru  n2- 1  RTR_6-  29- 1 3-  h  rs.  igx 


Elapsed  Time  in  Weeks 

25445.03 


Activity  Statistics  In  Weeks  (Hours) 


Count 

A^g  Cycle 

A\g  Work 

Serv 

A\g  Block 

SCO 

50.89 

50.69 

50.89 

0.00 

Activity  Statistics  in  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Awj  Work 

DT 

500 

45.91 

45.91 

40.51 

5.40 

Wait  until  all  certs  are  done. 

500 

40.33 

40.33 

40.33 

0.00 

IFC  Lead  Time 

1000 

29.86 

29.88 

29.88 

0.00 

E3IAR  Update 

1000 

29.68 

29.68 

27.45 

2  23 

Range  Safety  Lead  Time 

500 

25.97 

25.97 

23.30 

2.67 

IA&  CCA  Finish  Together 

500 

8.24 

8.24 

8.24 

0.00 

Finish  Together 

500 

8.08 

3.03 

8.03 

0.00 

Range  Safety 

500 

10.14 

10.14 

7.47 

2.68 

EMC  Lead  Time 

500 

0.54 

0.54 

0.00 

0.54 

EMI  Lead  Time 

500 

0.53 

0.53 

0.00 

0.53 

EMV  Lead  Time 

500 

25.72 

25.72 

0.00 

25.72 

EnvQual  Lead  Trme 

500 

2.31 

2.31 

0.00 

2.31 

Env  Qual 

500 

0.53 

0.53 

0.00 

0.53 

LRSB  Lead  Time 

500 

5,02 

5.02 

0.00 

5.02 

LRSR 

1500 

0.69 

0.89 

0.00 

0.89 

LASHAZEval  Lead  Time 

500 

4.90 

4.98 

0.00 

4.98 

LA.SHAZ  Eval 

1000 

1.99 

1.99 

0.00 

1.99 

LASER  Design  Checklist  Lead  Time 

500 

4.65 

4.65 

0.00 

4.65 

Develop  &  Build 

500 

0.00 

0.00 

0.00 

0.00 

FDA  Mil-Exempt  Letter  Lead  Time 

500 

2,99 

2.99 

0.00 

2.99 

FDA  MIL-Exempt  Letter 

1000 

0.53 

0.53 

0.00 

0.53 

IA  Lead  Time 

500 

0.00 

0.00 

0.00 

0.00 

IA  (Interim) 

500 

2.32 

2.32 

0.00 

2  32 

CCA  Lead  Time 

500 

8.59 

3.59 

0.00 

8.59 

CCA 

500 

1.97 

1.97 

0.00 

1.97 

Sys  Safety 

500 

10.02 

10.02 

0.00 

10.02 

PMA 

3000 

0.00 

0.00 

0.00 

0.00 

Start 

500 

0.00 

0.00 

0.00 

0.00 

End 

500 

0.00 

0.00 

0.00 

0.00 

DT  Lead  Time 

500 

4.93 

4.98 

0.00 

4.98 

IFC 

500 

1.99 

1.99 

0.00 

1.99 

E3IAR 

1500 

2.23 

2.23  ' 

0.00 

2.23 

EMC  {Intra-Sys  EMC) 

500 

0.22 

0.22 

0.00 

0  22 

EMI 

500 

2.22 

2.22 

0.00 

2  22 

EMV  (tnter-Sys  EMC) 

500 

2.49 

2.49 

0.00 

2.49 

LASER  Design  Checklist 

1000 

2.06 

2.06 

0.00 

2.06 

1/1 
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Summary  for  CycleTime  (Wks)  LASER  Designator  Run  2 IRTR 


ActivityName  =  End 


^  I  h 


95%  Confidence  Intervals 

Haann  i  m  — - 4 

h  | - * - 1 


Andereon-DaHing  Normality  Test 

A-Squared 

0.36 

P-Value 

0.446 

Mean 

50.890 

StDev 

12.041 

Variance 

144.991 

Skewness 

0.094760 

Kurtosis 

-0.317885 

N 

500 

Minimum 

22.548 

1st  Quartile 

42.723 

Median 

50.694 

3rd  Quartile 

59.528 

Maximum 

84.568 

95%  Confidence  Internal  For  Mean 

49.832 

51.948 

95%  Confidence  Internal  For  Median 

49.161 

52.238 

95%  Confidence  Interval  For  StDev 

11.338 

12.838 

49.0  49.5  50.0  50.5  51.0  5LS  52.0 


Process  Capability  of  CycleTime  (Wks)  LASER  Designator  Run  2  IRTR 


L-| - 1  |  1  I  1  1  1  1 1  1  I  1  |  i  I  l 

0.0  12.5  25.0  37.5  50.0  62.5  75.0 


Process  Data 

LB 

0 

Target 

52 

USL 

73 

Sample  Mean 

50.3901 

Sample  N 

500 

StDev(Within) 

11.7591 

StDev(Overal|) 

12.0412 

Potential  (Within)  Capability 

Cp 

* 

CPL 

* 

CPU 

0.77 

Cpfa 

0.77 

Overall  Capability 

Pp 

PPL 

* 

PPU 

0.75 

Ppk 

0.75 

Cpm 

0.72 

Observed  Performance 

Exp.  Within  Performance 

Exp.  Overall  Performance 

%  <  LB 

0.00 

%  <  LB  * 

%  <  LB  * 

%  >  USL 

1.20 

%  >  USL  1.06 

%  >  USL  1.22 

%  Total 

1.20 

%  Totai  1.06 

%  Total  1.22 
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Probability  Plot  of  CycleTime  (Wks)  LASER  Designator  Run  2 IRTR 

Normal 
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LASER  Designator  Run  2 
Low  Risk  Timeline  Reduction  (LRTR) 
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Elapsed  Time  in  Weeks 

25763.55 


RAI  N-Process-  Laser- Run  2-  LRTR_6-29- 1 3-hrs.  igx 


Activity  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

500 

51.53 

51.53 

0.00 

51.53 

Activity  Statistics  in  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

DT 

500 

45.91 

45.91 

40.51 

5.40 

IFC  Lead  Tme 

1000 

29.88 

29.88 

29.88 

0.00 

E3IAR  Update 

1000 

29.68 

29.68 

27.45 

2.23 

Wait  until  all  certs  are  done. 

500 

23.30 

23.30 

23.30 

0.00 

Range  Safety  Lead  Time 

500 

25.97 

25.97 

23.30 

2.67 

IA  &  CCA  Finish  Together 

500 

18.43 

18.43 

18.43 

0.00 

Finish  Together 

500 

8.08 

8.08 

8.08 

0.00 

Range  Safety 

500 

10.14  1 

10.14 

7.47 

2.68 

EMC  Lead  Time 

500 

0.54  1 

0.54 

0.00 

0.54 

EMI  Lead  Time 

500 

0.53 

0.53 

0.00 

0.53 

EMV  Lead  Time 

500 

25.72 

25.72 

0.00 

25.72 

Env  Qua!  Lead  Time 

500 

2.31 

2.31 

0.00 

2.31 

EnvQual 

500 

0.53 

0.53 

0.00 

0.53 

LRSB  Lead  Time 

500 

5.02 

5.02 

0.00 

5.02 

LRSB 

1500 

089 

089 

000 

089 

LASHAZE\al  Lead  Time 

500 

4.98 

4.98 

0.00 

4.98 

LASHAZEval 

I  1000 

1.99 

1.99 

0.00 

1.99 

LASER  Desgn  Checklist  Lead  Time 

500 

4.65 

4.65 

0.00 

4.65 

Develop  &  Build 

500 

0.00 

0.00 

000 

0.00 

FDA  MIL-Exempt  Letter  Lead  Time 

500 

2.99 

2.99 

0.00 

2.99 

FDA  MIL-Exempt  Letter 

1000 

0.53 

0.53 

0.00 

0.53 

IA  Lead  Time 

500 

25.71 

25.71 

0.00 

25.71 

IA  (Interim) 

500 

3.02 

3.02 

0.00 

3.02 

CCA  Lead  Time 

500 

8.59 

8.59 

0.00 

8.59 

CCA 

500 

1-97 

1.97 

0.00 

1.97 

Sys  Safety 

500 

10.02 

10.02 

0.00 

10.02 

PMA 

3000 

0.00 

0.00 

0.00 

0.00 

Start 

500 

0.00 

0.00 

0.00 

0.00 

End 

500 

0.00 

0.00 

0.00 

0.00 

DT  Lead  Time 

500 

4.98 

4.98 

0.00 

4.98 

IFC 

500 

199 

1.99 

0.00 

1.99 

E3IAR 

1500 

2.23! 

2.23 

0.00 

2.23 

EMC  (Intra-Sys  EMC) 

500 

0.22 

0.22 

0.00 

0.22 

EMI 

500 

2.22 

2.22  ! 

0.00 

2.22 

EMV  (Inter-Sys  EMC) 

500 

2.49 

2.49 

0.00 

2.49 

LASER  Design  Checklist 

1000 

2.06 

2.06 

0.00 

2.06 

1/1 
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Summary  for  CycleTime  (Wks)  LASER  Designator  Run  2  LRTR 


ActivityName  =  Endi 


93**fr  Confident  lnK**v*h 

Heart-  | - • - 

Hsian*  |  m  | 


Anderson-Darling  Normality  Test 

A-Squaetd 

&i43 

P-Value 

0.M5 

Mtin 

51527 

StDev 

11,354 

Vjria  nee 

128-924 

Skewness 

d,20Ol97 

Kurtosis, 

-0,205535 

N 

540 

Minimum 

22.653 

m  Qu^ilt 

43.147 

Median 

50.928 

frd  Qy  aiiile 

59,528 

Maximum 

84.588 

85%  Confidence  Internal  fqr  Meen 

50.528 

52.525 

85%  Confidence  Interval  for  Median 

49  .756 

52.283 

85%  Confidence  Internal  for  StDev 

10.69Z 

12.108 

>.T0  SO, 5  *>1  JO  S15  S2.5 


Process  Capability  of  CycleTime  (Wks)  LASER  Designator  Run  2  LRTR 


i — ■ — i  i  ^  . . . . . .  ■ 

0.0  12.5  25.0  37.5  50.0  62.5  75.0 


Process  Data 

LB 

O 

Target 

52 

USL 

73 

Sample  Mean 

51.5271 

Sample  N 

5O0 

StDev(Within) 

11.2018 

StDev(Overal[) 

11.3545 

Observed  Performance 

Exp.  Within  Performance 

Exp.  Overall  Performance 

%  ■=:  LB 

0.00 

%  <  LB  * 

%  <  LB  * 

%  >  USL 

1.20 

%  >  USL  0.95 

%  >  USL  0.99 

%  Total 

1.20 

%  Total  0.95 

%  Total  0.99 

Within 
—  —  Overall 


Potential  (Within)  Capability 

Op 

* 

CPL 

* 

CPU 

0.78 

Cpk 

0.78 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

0.78 

Ppk 

0.78 

Cpm 

0.76 

~ZZ¥J 


Probability  Plot  of  CycleTime  (Wks)  LASER  Designator  Run  2  LRTR 

Normal 


Mean 

51.53 

StDev 

11.35 

N 

500 

AD 

0.632 

P-Value 

0.099 
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LASER  Designator  Run  3 
Intermediate  Risk  Timeline  Reduction  (IRTR) 
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RAIN-Process-Laser-Run3-IRTR_6-29-13-hrs.igx 

Elapsed  Time  in  Weeks 

12693.39 


Activity  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

500 

25.39 

25.39 

0.00 

25.39 

Activity  Statistics  in  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Sen/ 

Avg  Block 

Avg  Work 

Wait  until  all  certs  are  done. 

500 

14.83 

14.83 

14.83 

0.00 

IA&  CCA  Finish  Together 

500 

8.24 

8.24 

8.24 

0.00 

Finish  Together 

500 

8.08 

8.08 

8.08 

0.00 

Range  Safety 

500 

10.14 

10.14 

7.47 

2.68 

Develop  &  Build 

500 

0.00 

0.00 

0.00 

0.00 

End 

500 

0.00 

0.00 

0.00 

0.00 

IFC 

500 

1.99 

1.99 

0.00 

1.99 

IFC  Lead  Time 

1000 

0.00 

0.00 

0.00 

0.00 

LRSB  Lead  Time 

500 

5.02 

5.02 

0.00 

5.02 

LRSB 

500 

0.89 

0.89 

0.00 

0.89 

LASER  Design  Checklist  Lead  Time 

500 

4.65 

4.65 

0.00 

4.65 

LASER  Design  Checklist 

1000 

2.06 

2.06 

0.00 

2.06 

IA  Lead  Time 

500 

0.00 

0.00 

0.00 

0.00 

IA  (Interim) 

500 

2.32 

2.32 

0.00 

2.32 

CCA  Lead  Time 

500 

8.59 

8.59 

0.00 

8.59 

CCA 

500 

1.97 

1.97 

0.00 

1.97 

Sys  Safety 

500 

10.02 

10.02 

0.00 

10.02 

PMA 

1500 

0.00 

0.00 

0.00 

0.00 

Start 

500 

0.00 

0.00 

0.00 

0.00 

Range  Safety  Lead  Time 

500 

2.67 

2.67 

0.00 

2.67 

1/1 
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Summary  for  CycleTime  (Wks)  LASER  Designator  Run  3  IRTR 

ActivityName  =  End 


16  20  24!  29  32  36  40 


95%  Confidence  Intervals 

| - • - 1 

Maid  i  -  | - • - 1 

2*J3  24.5  25A  25.5  26JQ 


Anderson-Darling  Normality  Test 

A-Squared 

4.20 

P-Value  < 

0.005 

Mean 

25.387 

St  Dev 

5.802 

Variance 

33.666 

Skewness 

0.436787 

Kurtosis 

-0.604498 

N 

500 

Minimum 

14.051 

1st  Quartile 

20.763 

Median 

24.652 

3rd  Quartile 

29.393 

Maximum 

40.801 

95%  Confidence  Interval  For  Mean 

24.877 

25.897 

95%  Confidence  Interval  For  Median 

24.097 

25.234 

95%  Confidence  Interval  For  StDev 

5.464 

6.186 

Process  Capability  of  CycleTime  (Wks)  LASER  Designator  Run  3  IRTR 


“  T  +  I  * 

□  11  22  33  44  55  66  77 


Process  Data 

LB 

0 

Target 

52 

USL 

78 

Sample  Mean 

25.3868 

Sample  N 

500 

StDev(Within) 

5.84716 

StDev(Overal[) 

5.80223 

Potential  (Within)  Capability 

Cp 

* 

CPL 

* 

CPU 

3.00 

Cpk 

3.00 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

3.02 

Ppk 

3.02 

Cpm 

0.32 

Observed  PetFomnance 

%  <  LB 

0.00 

%  >  USL 

0.00 

%  Total 

0.00 

Exp.  Within  PetFomnance 

Exp.  Overall  PetFomnance 

%  <  LB  * 

%  <  LB  * 

%  >  USL  0.00 

%  >  USL  0.00 

%  Total  0.00 

%  Total  0.00 
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Probability  Plot  of  CycleTime  (Wks^  LASER  Designator  Run  3 IRTR 

Normal 


Mean 

25.39 

StDev 

5.302 

H 

500 

AD 

4.196 

P-Value 

<0.005 
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LASER  Designator  Run  3 
Low  Risk  Timeline  Reduction  (LRTR) 
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RAIN- Pr™BE-LBBer-RLfi3-LRTR_6-aa-1 3-hrs.igx 


Eleps^d  Tiirw  in  Weeks 

1 6053  65 


Activity  SJiliitlti  In  VYetfca  t  Haunt] 


Count 

Avg  Ser-1 

Av^gWerk 

MQ 

32.14 

32.14 

0.00 

32.14 

Activity  5ta1  isEics-  in  VUc«ks  |Hourrs| 


Court 

Avg  Cycle 

BBBgg 

Avg  Work 

IA  &  CCA  Finish  Togelher 

500 

18.43 

1643 

0.00 

Wait  Lntilal  certs  are  done. 

500 

10.03 

10.03 

0.00 

Finish  Together 

K)0 

e.oe 

6.06 

0.00 

Kange  6alety 

500 

10.14 

10.14 

7.47 

H 

Develop  &  0LPtd 

500 

0.00 

0.00 

0.00 

6.CO 

bnd 

£00 

O.LKJ 

D.OD 

O.DD 

0.0(1 

IFC 

500 

1.9 9 

1.99 

0.00 

l.$& 

IFC  Lead  Time 

1000 

ODO 

D.OD 

D.DD 

000 

LfiSB  Lead  lime 

600 

6.D2 

D.DD 

LRSB 

MO 

o.eo 

0.00 

0.00 

0.5& 

LASER  Design  Checklist  Lead  Time 

500 

A.  65 

4.65 

0.00 

4.66 

LASER  Design  Checklist 

*  BXM 

2.06 

0.00 

IA  Lead  Timfc 

wrm 

25  71 

0  00 

LA  (liHerlm) 

500 

30 2 

Ha 

D.DD 

302 

CCA  Lead  Time 

£00 

£.59 

0.53 

O.DD 

S.5& 

CCA 

500 

1.07 

1.37 

D.DD 

1.97 

Sys  Safety 

MO 

10.02 

mm 

0.00 

10.02 

PIUA 

1500 

0  DO 

ODD 

DDD 

000 

Start 

500 

Q.DO 

D.OD 

D.DD 

0.00 

Range  Safety  Ljead  Time 

£00 

2.67 

0.00 

2.67 

Ut 
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Summary  for  CycleTime  (Wks)  LASER  Designator  Run  3  LRTR 


ActivityName  =  End 


95%  Confidence  Intervals 

Mejl  J  | - * - 


Andereon-DaHing  Normality  Test 

A-Squared 

lr89 

P-Value  < 

0.005 

Mean 

12.137 

StDev 

7.996 

Variance 

63.935 

Skewness 

0.3S7973 

Kurtosis 

-0.354624 

N 

500 

Minimum 

15.513 

1st  Quartile 

25.704 

Median 

31.630 

3rd  Quartile 

37.637 

Maximum 

54.400 

95%  Confidence  Interval  for  Mean 

31.435 

32.340 

95%  Confidence  Interval  for  Median 

30.640 

32.606 

95%  Confidence  Interval  for  StDev 

7.529 

8.525 

.0 


315 


12)1 


121 


13 .0 


Process  Capability  of  CycleTime  (Wks)  LASER  Designator  Run  3  LRTR 


Process  Data 

LB 

0 

Target 

52 

USL 

78 

Sample  Mean 

32.1373 

Sample  N 

500 

StDev(Within) 

8.12186 

StDev(OveralD 

7.99594 

- Within 

—  —  Overall 


Potential  (Within)  Capability 

Cp 

* 

CPL 

* 

CPU 

1.88 

Cpk 

1.88 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

1.91 

Ppk 

1.91 

Cpm 

0.40 

Observed  Performance 

%  <  LB 

0.00 

%  >  USL 

0.00 

%  Total 

0.00 

Exp.  Within  Performance 
%  <  LB  * 

%  >  USL  0.00 
%  Total  0.00 


Exp.  Overall  Performance 
%  <  LB  * 

%  >  USL  0.00 
%  Total  0.00 
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Probability  Plot  of  CycleTime  (Wks)  LASER  Designator  Run  3  LRTR 

Normal 


Mean 

32.14 

StDev 

7.396 

H 

500 

AD 

1.000 

P-Value 

<0.005 
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Passive  Electronic  Warfare  (EW)  Run  1 
Intermediate  Risk  Timeline  Reduction  (IRTR) 


253 


KAiwamvel  W4tun-l-fRIR_tv-7M 3-hn  igi 


Elapsed  Tim w  in  Weeks 

[46019831 

Transaction  Statistics  to  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Scrv 

Avg  Bock  Avg  Work 

SOO 

92  04 

92  01 

0  00  92  04 

Activity  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle  |  Avg  Serv 

Avg  Block 

Avg  Work 

cn 

1000 

60  50 

60  50 

0  00 

60  50 

SAASMHAE 

500 

59  94 

59  94 

0  00 

59  94 

H8»  Testng  Lead  Tme 

500 

35  83 

35  83 

9  84 

25  99 

EMV  lead  In* 

f>00 

75  /? 

75  D 

0  00 

75/7 

Sys  Safety 

500 

1002 

10  02 

000 

10  02 

CCA  lead  Tme 

500 

78  70 

78  70 

7011 

859 

WSESRB  Lead  Tme 

750 

833 

833 

000 

833 

WRPSRR 1  ead  Tme 

750 

8  30 

8.30 

0  00 

830 

SAASMUrsqn  Heq'storHAL  Lead  lime 

500 

806 

806 

000 

806 

HBW  Test  Report 

500 

8  03 

803 

000 

803 

1  req  Assignments 

7000 

6  Of. 

6  05 

0  00 

605 

Intru  m  Gqu  p  Spectrum  Cerit 

500 

C  02 

602 

000 

602 

DT 

500 

77  4  7 

77  47 

77  07 

540 

L)1  Lead  lime 

500 

498 

498 

000 

4  98 

Range  Safety 

500 

10  14 

10  14 

/  4  / 
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Range  Safety  Lead  lime 

500 

64  58 

64  58 

61  92 

26/ 

HERO  Testng 

500 

2  51 

251 

000 

251 

BN  (Inter -Sys  BrlC) 

500 

18  81 

18  81 

16  32 

249 

Cattery  Approval  Checklist 

1000 

2  37 

237 

000 

237 

IA  (kitwinl 

500 

232 

232 

000 

232 

Biv  Qual  Lead  Tme 

500 

2  31 

231 

0  00 

231 

E3IAR 

4000 

223 

223 

0  00 

223 

E3IAR  Update 

1000 

60  54 

60  54 

58  31 

223 

B.I 

500 

222 

222 

000 

222 

FC 

500 

199 

199 

000 

199 

CCA 

500 

197 

197 

000 

197 

SAASMDwgn  Reg's  for  HAE 

1000 

169 

169 

000 

169 

Bonding  A  Grounding 

500 

111 

111 

000 

111 

HB*> 

500 

111 

111 

000 

111 

hfpo 

500 

1 11 

111 

000 

111 

ESC 

500 

1 11 

111 

0  00 

1 11 

HBF 

500 

1 11 

111 

000 

111 

WiKNH 

750 

0  5/ 

057 

0  00 

05/ 

WRFRRR 

750 

056 

056 

0  00 

056 

RARHA7  Analysis  l  ead  Tme 

500 

0  55 

055 

0  00 

055 

IMS  Lead  tire 

500 

10  38 

10  J8 

9  84 

054 

LM  Lead  1  me 

500 

053 

053 

0  00 

053 

Invtkial 

1000 

0  53 

053 

0  00 

053 

ESD  Lead  Time 

500 

0  53 

053 

000 

053 

Bonding  &  Groundnq  Lead  Time 

500 

0  52 

052 

000 

052 

KACtIAZ  Analysis 

500 

044 

044 

0  00 

044 

LMC  (htra-Sys  LMC) 

500 

022 

022 

0  00 

022 

Start 

500 

0  CD 

000 

000 

000 

Bid 

500 

000 

000 

000 

000 

Develop  &  Buid 

500 

000 

000 

000 

000 

FC  Lead  Time 

1000 

62  09 

62  09 

62  09 

000 

IA  Lead  Tine 

500 

2011 

2011 

2011 

000 

JTTC 

500 

_ a  oo 

000 

000 

000 

SAASMHAE  Lead  Tme 

500 

000 

000 

000 

000 

Wait  unM  al  certs  aie  done 

500 

15  92 

15  92 

15  92 

000 

Equp  Spectrum  Cert  Lead  Time 

500 

000 

000 

000 

000 

Battery  Approv  ai  Lead  Tme 

500 

000 

000 

000 

000 

Freq  Assignments  Lead  Time 

500 

000 

000 

000 

000 

Repeat1 

500 

000 

000 

000 

000 

Repealed1 

750 

000 

000 

000 

000 

FM\ 

3500 

000 

000 

000 

000 

.ITC 1  ead  Tme 

500 

000 

0  00 

0  00 

000 

Repeated1  w  t 

750 

000 

000 

000 

000 

Repeat1  w  1 

500 

000 

000 

000 

000 

Colert  Inputs 

500 

o  n 

0/3 

0/3 

000 

ColectHBK)  Re  suits 

500 

4205 

42  05 

42  05 

000 

Colert  WSPRRR  Resists 

500 

000 

0  00 

0  00 

0  00 

lA&UCAImish  logether 

500 

8  24 

824 

824 

000 

VkKfSRR  Outputs 

500 

000 

0  00 

0  00 

000 

finish  logefher 

500 

808 

808 

808 

000 

Metr  i 

S^si^n 


Summary  for  CycleTime  (Wks)  Passive  EW  Run  1 IRTR 


AchvityName  =  End 


95%  Confidence  Intervals 


h 


■i 


Andereon-DaHing  Normality  Test 

A-Squared 

0.44 

P-Value 

0.290 

Mean 

92.040 

StDev 

12.379 

Variance 

153.230 

Skewness 

0.065395 

Kurtosis 

-0.210919 

N 

500 

Minimum 

57.166 

1st  Quartile 

33.115 

Median 

91.803 

3rd  Quartile 

100.478 

Maximum 

126.370 

95%  Confidence  Interval  For  Mean 

90.952 

93.127 

95%  Confidence  Interval  For  Median 

99.784 

93.854 

95%  Confidence  Interval  For  StDev 

11.656 

13.197 

9Q  9L  92  93  9* 


Process  Capability  of  CycleTime  (Wks)  Passive  EW  Run  1  IRTR 


LB 


Process  Data 

LB 

0 

Target 

52 

USL 

78 

Sample  Mean 

92.0397 

Sample  N 

500 

StDev(Within) 

12.718 

StDev(Overal[) 

12.3786 

Observed  Performance 

Exp.  Within  Performance 

Exp.  Overall  Performance 

%  <  LB  0.00 

%  <  IB  * 

%  <  LB  * 

%  >  USL  87.40 

%  >  USL  86.52 

%  >  USL  87.16 

%  Total  87.40 

%  Total  86.52 

%  Total  87.16 

- Within 

—  —  Overall 


Potential  (Within)  Capability 

Cp 

CPL 

* 

CPU 

-0.37 

Cpk 

-0.37 

Overall  Capability 

Pp 

* 

PPL 

PPU 

-0.38 

Ppk 

-0.38 

Cpm 

0.21 
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Probability  Plot  of  CycleTime  (Wks)  Passive  EW  Run  1 IRTR 

Normal 


Mean 

92.04 

StDev 

12 .38 

N 

500 

AD 

0.441 

P-Value 

0.290 
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Passive  Electronic  Warfare  (EW)  Run  1 
Intermediate  Risk  Timeline  Reduction  (LRTR) 


y 
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RAW-Pas  aveCW-Run  -1  -LRTR_6-29- 1 3-hrs  jp 


Bapsed  Time  in  Weeks 

janaifts?  | 


Transaction  Suite  dot  InWMkt  (Hours) 


Count 

TVq  Cycle 

1 

t 

hx\  Bloc* 

A\qW>r1c 

500 

76.64 

76.64 

0.00 

76.64 

Activity  Statistic  5  In  Weeks  |Hours) 


Count 

AvcjQcle 

Awj  Seiv 

AvgBItiLk 

AkjVM 

HERO  Testhg  LeadTme 

500 

29.91 

29.81 

3.82 

25.99 

EMV  Lead  Time 

500 

25.72 

25.72 

0.00 

2572 

IA  Lead  lime 

600 

25.71 

26.71 

0.00 

2571 

JTC 

500 

11.66 

11.66 

0.00 

11.66 

ftp  Safely 

non 

100? 

inn? 

000 

100? 

CCA  Lead  Time 

500 

3.59 

9.69 

0.00 

9.59 

W3E5RB  Lead  Time 

750 

833 

933 

0.00 

933 

W5£5RB  Lead  Time 

750 

330 

9.30 

0.00 

9.30 

HERO  Test  Re  p«1 

500 

8.03 

9.03 

0.00 

9.03 

JTC  Lead  lime 

600 

7.9/ 

7.U7 

0.00 

7.87 

Fneqtesignmerlls 

2000 

6.05 

6.05 

0.00 

605 

FIT 

non 

71  on 

71  05 

fifi?5 

540 

DT  Lead  Time 

500 

498 

468 

0.00 

4.99 

IA  (Interim) 

500 

3.02 

3.02 

0.00 

302 

Range  Safety 

500 

10.14 

10.14 

7.47 

2.69 

Range  Safety  Lead  1  mne 

500 

61.14 

61.14 

511.47 

2.67 

limO  Testiig 

500 

?51 

?51 

OOO 

?51 

FMVjhtr^sFHC) 

non 

2409 

?4SO 

21  90 

249 

ErivQual  LeadTime 

500 

231 

2.31 

0.00 

2.31 

E3IAR 

4000 

223 

223 

0.00 

223 

E3IAR  Update 

1000 

54.72 

54.72 

52.50 

223 

EMI 

500 

222 

222 

0.00 

222 

IRC 

m 

1  as 

100 

m 

190 

CCA 

500 

197 

107 

0.00 

1.97 

Bonding  &  Grounding 

500 

1.11 

1.11 

m 

HFRP 

non 

1 11 

1 11 

000 

HI 

HERO 

500 

1.11 

1.11 

0.00 

E5D 

500 

1.11 

111 

0.00 

1.11 

HERE 

500 

1.11 

1.11 

0.00 

1.11 

WStSHB 

750 

0.6/ 

057 

0.00 

057 

W5C5RB 

750 

0.56 

0.56 

0.00 

0.56 

RARHA7  Analysis  lead  Time 

non 

055 

055 

OOO 

055 

EMC  Lead  Time 

500 

436 

4.36 

3.82 

0.54 

EMI  Lead  Time 

500 

0.53 

053 

0.00 

0.53 

ErwQual 

1000 

0.53 

053 

0.00 

0.53 

LSD  bead  lime 

500 

063 

053 

0.00 

053 

Bonding  4  Grounding  Lead  Time 

500 

0.52 

052 

0.00 

0.52 

RJOWAn^ysis 

non 

044 

044 

000 

044 

EMC  [Intia-Sys  BWC) 

500 

022 

022 

0.00 

022 

Start 

500 

030 

0.00 

0.00 

0.00 

Will  until  all  certs  arc  done. 

500 

47.79 

47.78 

47.78 

0.00 

Develop  a  Build 

500 

01)0 

0.00 

0.00 

0.00 

Fnrl 

500 

000 

000 

000 

000 

IRC  1  pad  Time 

1000 

5047 

5947 

5847 

000 

Repeat? 

non 

000 

000 

OOO 

000 

Repealed? 

750 

030 

OOO 

0.00 

0.00 

Freq  Assignment  LeadTime 

500 

030 

0.00 

0.00 

OOO 

PMA 

4000 

030 

0.00 

0.00 

0.00 

Repeated?  wl 

750 

0.00 

0.00 

0.00 

0.00 

Repeat?  wl 

non 

000 

000 

OOO 

000 

Collect  Inputs. 

500 

0.73 

0.73 

0.73 

0.00 

Culled  HERO  Re  yu  Its 

500 

36.06 

38.05 

36.05 

0.00 

Collect  VKESRB  Results 

500 

0.00 

0.00 

0.00 

000 

IA&  CCA  Finish  Together 

500 

10.43 

19.43 

1843 

0.00 

WSLSHB  Outputs 

500 

030 

0.00 

0.00 

000 

Finish  Together 

non 

808 

908 

90ft 

000 
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Summary  for  CycleTime  (Wks)  Passive  EW  Run  1  LRTR 

ActivityName  -  End 


1 - h 


95%  Confidence  Intervals 


Metri 


?5jQ 


?5  5 


Andereon-DaHing  Normality  Test 

A-Squared 

0.83 

P-Value 

0.032 

Mean 

76.638 

StDev 

13.373 

Variance 

178.846 

Skewness 

0.373863 

Kurtosis 

0.092144 

N 

500 

Minimum 

44.054 

1st  Quartile 

67.062 

Median 

75.825 

3rd  Quartile 

85.011 

Maximum 

119.304 

95%  Confidence  Interval  for  Mean 

75.463 

77.813 

95%  Confidence  Interval  for  Median 

75.043 

77.156 

95%  Confidence  Interval  for  StDev 

12.593 

14.258 

Process  Capability  of  WorkTime  (Wks)  Passive  EW  Run  1  LRTR 


Observed  Performance 
%  <  LB  0.00 
%  >  USL  42.20 
%  Total  42.20 


Process  Data 

LB 

0 

Target 

52 

USL 

78 

Sample  Mean 

76.6378 

Sample  N 

500 

StDev(Within) 

13.5583 

StDev(Overal[) 

13.3733 

Within 

Overall 


Potential  (Within)  Capability 

CP 

* 

CPL 

* 

CPU 

0.03 

Cpk 

0.03 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

0.03 

Ppk 

0.03 

Cpm 

0.31 

20 


40 


60 


SO 


100  120 


Exp.  Within  Performance 
%  <  LB  * 

%  >  USL  46.00 
%  Total  46.00 


Exp.  Overall  Performance 
%  <  LB  * 

%  >  USL  45.94 
%  Total  45.94 
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Probability  Plot  of  CycleTime  (Wks)  Passive  EW  Run  1  LRTR 

Normal 


Mean 

76.64 

StDev 

13.37 

H 

500 

AD 

0.831 

P-Value 

0.032 

260 


Passive  Electronic  Warfare  (EW)  Run  2 
Intermediate  Risk  Timeline  Reduction  (IRTR) 


r-.  — 
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RA I  N-PassiveE  W-R  un-2-l  RTR6-29-1 3-  hrs  igx 


Elapsed  Time  in  Weeks 

I  25417.91  I 


Transaction  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

500 

50.84 

50.04 

0.00 

50.84 

Activity  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

EMV  Lead  Time 

500 

25  72 

25.72 

0.00 

25  72 

5ys  Safety 

500 

10.02 

10.02 

0.00 

10.02 

CCA  Lead  Time 

500 

359 

3.59 

0  00 

8.59 

DT 

500 

45.85 

45.85 

40.45 

5.40 

DT  Lead  Time 

500 

4.98 

4.98 

0.00 

4.98 

Range  Safety 

500 

10.14 

10.14 

7.47 

2.68 

Range  Safety  Lead  Time 

500 

2.67 

2.67 

0  00 

2.67 

EMV  (Inter-Sys  EMC) 

500 

2.49 

2.49 

0.00 

2.49 

1A  (Interim) 

500 

2.32 

2.32 

0.00 

2.32 

invQuel  Lead  Time 

500 

2,31 

2.31 

0,00 

2,31 

E3IAR 

1500 

223 

2.23 

0.00 

2  23 

E3IAR  Update 

1000 

29.68 

29.68 

27.45 

2.23 

EMI 

500 

222 

2.22 

0.00 

2  22 

IFC 

500 

1  99 

1.99 

0  00 

1.99 

CCA 

500 

1.97 

1.97 

0.00 

1.97 

EMC  Lead  Time 

500 

0.54 

0.54 

0.00 

0.54 

EMI  LeadTime 

500 

0.53 

0.53 

0  00 

0.53 

Em  Qual 

500 

0.53 

0.53 

0  00 

0.53 

EMC  (Intra-Sys  EMC) 

500 

0.22 

0.22 

0.00 

0  22 

Develop  &  Buitd 

500 

0.00 

0.00 

0.00 

0.00 

End 

500 

0.00 

0.00 

0  00 

0.00 

IFC  LeadTime 

1000 

29.83 

29.83 

29.83 

0.00 

JA  Lead  Time 

500 

0.00 

0.00 

0  00 

0.00 

PM  A 

2500 

0.00 

0.00 

0.00 

0.00 

Start 

500 

0.00 

0.00 

0.00 

0.00 

Wait  until  all  certs  are  done. 

500 

40.28 

40.28 

40.28 

0.00 

JA  &  CCA  Finish  Together 

500 

824 

8.24 

8.24 

0.00 

Finish  Together 

500 

3.08 

3.08 

8.  OS 

0.00 

1/1 
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Summary  for  CycleTime  (Wks)  Passive  EW  Run  2 IRTR 

ActivityName  =  End 


H  I  h 


95%  Confidence  Intervals 


*15 


5Q  n 


saii 


sin 


51 5 


52  a 


Anderson-Darling  Normality  Test 

A-Squared 

0.30 

P-Value 

0.533 

Mean 

50.836 

StDev 

12.135 

Variance 

147265 

Skewness 

0.062106 

Kurtosis 

-0.281635 

N 

500 

Minimum 

20.066 

1st  Quartile 

42.723 

Median 

50.694 

3rd  Quartile 

59.528 

Maximum 

84.568 

95%  Confidence  Interval  for  Mean 

49.77Q 

51.902 

95%  Confidence  Interval  for  Median 

49.169 

52238 

95%  Confidence  Interval  for  StDev 

11.427 

12.938 

Process  Capability  of  CycleTime  (Wks)  Passive  EW  Run  2  IRTR 


Process  Data 

LB 

0 

Target 

52 

USL 

78 

Sample  Mean 

50.8358 

Sample  N 

500 

StDev(Within) 

11.8421 

StDev(Overalp 

12.1353 

Observed  Performance 
%  <  LB  0.00 
%  >  USL  1.20 
%  Total  120 


Within 

Overall 


Potential  (Within)  Capability 

Cp 

* 

CPL 

* 

CPU 

0.76 

Cpk 

0.76 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

0.75 

Ppk 

0.75 

Cpm 

0.71 

12.5  25.0  37.5  50.0  62.5  75.0 


Exp.  Within  Performance 
%  <  LB  * 

%  >  USL  1.09 
%  Total  1.09 


Exp.  Overall  Performance 
%  <  LB  * 

%  >  USL  126 
%  Total  126 
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Probability  Plot  of  CycleTime  (Wks)  Passive  EW  Run  2 IRTR 

Normal 


98,740 


Mean 

50.34 

StDev 

12.14 

H 

500 

AD 

0.299 

P-Value 

0.503 
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Passive  Electronic  Warfare  (EW)  Run  2 


265 


Low  Risk  Timeline  Reduction  (LRTR) 
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RAI  rt««lftEW-Rurva-LRTR>Z9  - 1 3  ITS  IgH 


Ei?p*»ti  Time  irt  w«m 

I  25745.50  I 


Transaction  Statistics  In  Weeks  (Hours) 


COWt 

Avg  Cycle 

AV0  BIfrCSc 

Avg  work 

500 

51 .40 

51  4* 

0.00 

51.49 

Activity  Statistic*  In  Weeks  (Hpufij 


COurll 

Avg  Cycle 

Avg  Serv 

Avg  EbCk 

Av£  Work 

EMV  Lead  Time 

500 

25.72 

25.72 

0.00 

25.72 

IA  lead  Time 

5DD 

25  71 

25  71 

000 

25,71 

Sys  safely 

500 

10  02 

10,02 

0  00 

10.02 

cca  Lead  Time 

5D0 

3  59 

5  59 

QOO 

359 

DT 

500 

45  95 

45.65 

40.45 

5  40 

DT  Lead  Tirm 

500 

4  00 

499 

000 

4  OS 

IA  {interim) 

500 

3.02 

3.02 

000 

3.02 

Range  Safely 

500 

10  14 

10.14 

7  47 

2.58 

Range  Safety  Lead  Time 

500 

2  67 

2.67 

000 

t  87 

EM^(lrtt#r-£yfl  EMC) 

tiUU 

1 40 

340 

000 

£46 

Err.'  QlbI  Lead  Time 

500 

2.31 

2.31 

0.00 

2.3- 

ESlAft 

isoo 

2  23 

2.23 

000 

2.23 

E3IAR  Update 

1000 

29  53 

29.63 

27.45 

2.28 

EMI 

500 

2  22 

2  22 

000 

2  22 

IFC 

1.99 

1.00 

0.00 

1.59 

CCA 

500 

1.97 

1.07 

0.00 

1.97 

EMC  Lead  Tima 

500 

0.54 

0.54 

0.00 

0.54 

EMI  Lead  Time 

500 

0  53 

0.53 

0.00 

0.53 

Err--  Qcal 

500 

0  53 

0.53 

0.00 

0.53 

EMC  (IrUra-Sys  EMC) 

500 

0.22 

0.22 

0.00 

0.22 

Develop  il  Build 

500 

0  00 

0.00 

000 

0.00 

End 

500 

0  00 

O.OD 

000 

000 

IFC  Lead  Time 

1DDQ 

29  03 

29.63 

29.33 

QOO 

PMA 

2500 

0.00 

0.00 

0.00 

0.00 

Start 

500 

0.00 

0.00 

0.00 

0.00 

Wait  until  all  carls  are  done. 

500 

23.23 

23.29 

23.28 

0.00 

IA  &  CCA  Fiii&h  T&gdher 

500 

1943 

19.43 

19.43 

0.00 

Finish  Tdgelher 

500 

9  09 

S.09 

9  08 

0.00 

1V1 
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Summary  for  CycleTime  (Wks)  Passive  EW  Run  2  LRTR 

ActivityName  =  End 


h - T 


95%  Confidence  Intervals 


Mean 


50  JQ 


505 


51 .0 


515 


52  JQ 


525 


Andereon-DaHing  Normality  Test 

A-Squared 

0.56 

P-Value 

0.143 

Mean 

51.491 

StDev 

11.414 

Variance 

130.233 

Skewness 

0.173151 

Kurtosis 

-0.137652 

N 

500 

Minimum 

22.653 

1st  Quartile 

43.147 

Median 

50.923 

3rd  Quartile 

59.523 

Maximum 

34.563 

95%  Confidence  Interval  for  Mean 

50 .438 

52.494 

95%  Confidence  Interval  for  Median 

49.756 

52.233 

95%  Confidence  Interval  for  StDev 

10.743 

12.169 

Process  Capability  of  CycleTime  (Wks)  Passive  EW  Run  2  LRTR 


Process  Data 

LB 

0 

Target 

52 

USL 

73 

Sample  Mean 

51.491 

Sample  N 

500 

StDevfWithin) 

11.3333 

StDev(Overal[) 

11.4142 

Within 

Overall 


Potential  (Within)  Capability 

Cp 

CPL 

* 

CPU 

0.78 

Cpk 

0.73 

Overall  Capability 

Pp 

$ 

PPL 

* 

PPU 

0.77 

Ppk 

0.77 

Cpm 

0.76 

0.0  12.5  25.0  37.5  50.0  62.5  75.0 


Observed  Performance 
%  <  LB  0.00 
%  >  USL  1.20 
%  Total  1.20 


Exp.  Within  Performance 
%  <  LB  * 

%  >  USL  0.97 
%  Total  0.97 


Exp.  Overall  Performance 
%  <  LB  * 

%  >  USL  1.01 
%  Total  1.01 


Probability  Plot  of  CycleTime  (Wks)  Passive  EW  Run  2  LRTR 

Normal 


93,990 


51,773 


Mean 

51,49 

StDev 

11.41 

N 

500 

AD 

0.559 

P-Value 

0.148 
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Passive  Electronic  Warfare  (EW)  Run  3 
Low  Risk  Timeline  Reduction  (IRTR) 


270 


271 


RA  N-Pas&iveE  W -Run-3-IR7R_6-29- 1 3-hrs.  ig* 


Elapsed  Time  in  Weeks 
I  7065.64 


Transaction  Statistics  In  Weeks  { Hours) 


Count 

SM 

Ayg  Cycle 

A^g  Serv 

A-jg  Blsch 

Ayg  Work 

14.13 

14.13 

D.CO 

14.13 

Activity  Statistics  In  Weeks  (Hours} 


count 

Aug  cycle 

Av#  serv 

Ay£  Block 

Avd  Work 

Sys  Safety 

500 

10.02 

0.00 

10.02 

CCA  Lead  Time 

500 

e.B9 

e.5s 

0.00 

a.  5^ 

Range  Safety 

500 

10.14 

10.14 

747 

2.60 

Range-  Safely  Lead  Time 

2.67 

2  67 

0.00 

2.67 

IA  (Interim) 

2.32 

2  32 

0.00 

2.32 

IFC 

500 

1.99 

0.00 

1.99 

CCA 

BOO 

197 

0.00 

1.97 

De^lop  &  Build 

500 

O.QQ 

0  DO 

0.00 

0.00 

End 

500 

D.OO 

D.OO 

0.00 

0.00 

IFC  Lead  Time 

1000 

0.00 

D.OO 

0.00 

0.00 

IA  Lead  Tima 

500 

0.00 

D.OO 

0.00 

0.00 

PMA 

2000 

0.00 

0.00 

0.00 

0.00 

Slarl 

BOO 

0.00 

0.00 

0.00 

0.00 

Wail  until  all  certs  are  done 

500 

4.03 

4  93 

4.91 

0.1X1 

IA  5  CCa  FlmsH  Togolhe* 

6.24 

6.24 

6.24 

0.00 

Finish  Together 

500 

6.00 

6.06 

6.06 

0.00 

11 
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Summary  for  CycleTime  (Wks)  Passive  EW  Run  3 IRTR 

Activity  Name  =  End 


95%  Confidence  Intervals 

ih  | - • - 1 

Wal  Ji  1  | - * - 1 

120  12.5  130  0.5  i^JO  145 


9  12  15  O  21  2*  27 


2 


Andereon-Dariing  Normality  Test 

A-Squared 

19.40 

P-Value  < 

0.005 

Mean 

14.12S 

StDev 

4.450 

Variance 

19.005 

Skewness 

0.973209 

Kurtosis 

0.010494 

N 

500 

Minimum 

7.565 

1st  Quartile 

10.975 

Median 

12.466 

3rd  Quartile 

16.047 

Maximum 

27.243 

95%  Confidence  Interval  For  Mean 

13.737 

14.519 

95%  Confidence  Interval  For  Median 

12.101 

12.939 

95%  Confidence  Interval  For  StDev 

4.191 

4.745 

Process  Capability  of  CycleTime  (Wks)  Passive  EW  Run  3  IRTR 


Process  Data 

LB 

0 

Target 

52 

USL 

70 

Sample  Mean 

14.1277 

Sample  N 

500 

StDev(Within) 

4.12767 

StDev(Cveral[) 

4.45032 

_ _ USL 


- Within 

—  —  Overall 


Potential  (Within)  Capability 

CP 

* 

CPL 

* 

CPU 

5.16 

Cpk 

5.16 

Cverall  Capability 

Pp 

* 

PPL 

PPU 

4.70 

Ppk 

4.70 

Cpm 

0.23 

Cbserved  Performance 

%  <  LB 

0.00 

%  >  USL 

0.00 

%  Total 

0.00 

Exp.  Within  Performance 
%  <  LB  * 

%  >  USL  0.00 
%  Total  0.00 


Exp.  Cverall  Performance 

%  <  LB 

* 

%  >  USL 

0.00 

%  Total 

0.00 
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Probability  Plot  of  CycleTime  (Wks)  Passive  EW  Run  3  IRTR 

Normal 


Mean 

14.13 

StDev 

4.450 

N 

500 

AD 

19.404 

P-Value 

<0.005 
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Passive  Electronic  Warfare  (EW)  Run  3 
Low  Risk  Timeline  Reduction  (LRTR) 


275 


276 


RAIN-Pa&&i^E  W-Run-3-LRTR_6-2S- 1  3-hrs  .ig* 


Elapsed  Time  m  Weeks 
14631  35 


Transaction  Statistics  In  Weeks  ^curs) 


Count 

Avg  CycEe 

Avq  Serv 

Avg  Block 

Avg  W&rk 

BOO 

29.2fi 

2&.2S 

0  00 

29.26 

Activity  Statistics  In  Weeks  (Fkiura} 


Count 

Avg  Cycle 

Ayg  Serv 

Avg  Block 

Avg  Work. 

IA  Lead  Tima 

5O0 

25.71 

25.71 

O.OO 

25.71 

Sys  Safety 

5O0 

10.02 

10.02 

O.OO 

10.O2 

CCA  Lead  Time 

5O0 

0.59 

Km 

O.OO 

8.59 

fA  (Inltrim) 

500 

3  02 

3.02 

0.00 

3  02 

Range  surety 

5O0 

10  14 

10.14 

7.47 

2 

Sjnge  Safety  Leed 

500 

2  07 

2.07 

0.00 

2.57 

IFC 

500 

1.99 

1.99 

0.00 

1.99 

CCA 

50Q 

1  97 

1.97 

0.00 

1  9? 

Develop  &  Build 

5O0 

0.09 

O.OO 

0.00 

O.OO 

End 

500 

O.09 

O.O0 

0.00 

0.00 

IFC  Lead  Time 

1000 

0.09 

O.DQ 

0.00 

Q.C0 

PMA 

0  OC 

0.00 

0.00 

0  CO 

Start 

500 

0.09 

0.00 

O.OO 

0.00 

Wait  until  all  certs  are  done. 

5O0 

16.99 

16.90 

16.90 

0.00 

IA  S  CCA  Finish  Togcmer 

500 

1B4$ 

10.43 

mm 

0  00 

Finish  Together 

5O0 

0.0S 

£.00 

6. 0B 

0.00 

in 
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Summary  for  CycleTime  (Wks)  Passive  EW  Run  3  LRTR 

ActivityName  =  End 


7£  isa  225  3Q.Q  175  45Jt]  S25 


H  I 


95%  Confidence  Intervals 


f+2* 1 


Hedan 


27Q 
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,29  JQ 


2M5 


29  JQ 


29.5 


3QJQ 


Anderson-Darling  Normality  Test 

A-Squared 

1.50 

P-Value  < 

0.005 

Mean 

29.263 

StDev 

10.035 

Variance 

100.711 

Skewness 

0.218345 

Kurtosis 

-0.579144 

N 

500 

Minimum 

8.217 

1st  Quartile 

22.058 

Median 

28.469 

3rd  Quartile 

36.883 

Maximum 

54.400 

95%  Confidence  Internal  for  Mean 

28.3S1 

30.145 

95%  Confidence  Internal  for  Median 

28.928 

29.516 

95%  Confidence  Interval  for  StDev 

9.450 

10.699 

Process  Capability  of  CycleTime  (Wks)  Passive  EW  Run  3  LRTR 


T  V  b|1  V  r  V  'r  V  1,11  1  i 

0  10  20  30  40  50  60  70 


Process  Data 

LB 

O' 

Target 

52 

USL 

78 

Sample  Mean 

29.2628 

Sample  N 

500 

StDev(Within) 

10.2631 

StDev(Overal[) 

10.0355 

Potential  (Within)  Capability 

Cp 

* 

CPL 

* 

CPU 

1.58 

Cp k 

1.58 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

1.62 

Ppk 

1.62 

Cpm 

0.35 

Observed  Performance 

Eip.  Within  Performance 

Eip.  Overall  Performance 

%  *  LB 

0.00 

%  <  LB  * 

%  <  IB  * 

%  >  USL 

0.00 

%  >  USL  0.00 

%>USL  fl.OO 

%  Total 

0.00 

%  Total  0.00 

%  Total  0.00 
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Probability  Plot  oF  CycleTime  (Wks)  Passive  EW  Run  3  LRTR 

Normal 


Mean 

29  26 

StDev 

10.04 

N 

500 

AD 

1.500 

P-Value 

<0.005 
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Active  Electronic  Warfare  (EW)  Run  1 
Intermediate  Risk  Timeline  Reduction 


R) 


280 


RAIN-PassiveEW-Run-1  -IRTR_6-29-13-hrs.igx 


Elapsed  Time  in  Weeks 

|46019.83  | 


Transaction  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

500 

92.04 

92.04 

0.00 

92.04 

Activity  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

CDL 

1000 

60.50 

60.50 

0.00 

60.50 

SAASM  HAE 

500 

59.94 

59.94 

0.00 

59.94 

HERO  Testing  Lead  Time 

500 

35.83 

35.83 

9.84 

25.99 

EMV  Lead  Time 

500 

25.72 

25.72 

0.00 

25.72 

Sys  Safety 

500 

10.02 

10.02 

0.00 

10.02 

CCA  Lead  Time 

500 

28.70 

28.70 

20.11 

8.59 

WSESRB  Lead  Time 

750 

8.33 

8.33 

0.00 

8.33 

WSESRB  Lead  Time 

750 

8.30 

8.30 

0.00 

8.30 

SAASM  Design  Reg's  for  HAE  Lead  Time 

500 

8.06 

8.06 

0.00 

8.06 

HERO  Test  Report 

500 

8.03 

8.03 

0.00 

8.03 

Freg  Assignments 

2000 

6.05 

6.05 

0.00 

6.05 

Intrum  Equip  Spectrum  Certt 

500 

6.02 

6.02 

0.00 

6.02 

DT 

500 

77.47 

77.47 

72.07 

5.40 

DT  Lead  Time 

500 

4.98 

4.98 

0.00 

4.98 

Range  Safety 

500 

10.14 

10.14 

7.47 

2.68 

Range  Safety  Lead  Time 

500 

64.58 

64.58 

61.92 

2.67 

HERO  Testing 

500 

2.51 

2.51 

0.00 

2.51 

EMV  (Inter-Sys  EMC) 

500 

18.81 

18.81 

16.32 

2.49 

Battery  Approval  Checklist 

1000 

2.37 

2.37 

0.00 

2.37 

IA  (Interim) 

500 

2.32 

2.32 

0.00 

2.32 

Env  Qual  Lead  Time 

500 

2.31 

2.31 

0.00 

2.31 

E3IAR 

4000 

2.23 

2.23 

0.00 

2.23 

E3IAR  Update 

1000 

60.54 

60.54 

58.31 

2.23 

EMI 

500 

2.22 

2.22 

0.00 

2.22 

IFC 

500 

1.99 

1.99 

0.00 

1.99 

CCA 

500 

1.97 

1.97 

0.00 

1.97 

SAASM  Design  Req's  for  HAE 

1000 

1.69 

1.69 

0.00 

1.69 

Bonding  &  Grounding 

500 

1.11 

1.11 

0.00 

1.11 

HERP 

500 

1.11 

1.11 

0.00 

1.11 

HERO 

500 

1.11 

1.11 

0.00 

1.11 

ESD 

500 

1.11 

1.11 

0.00 

1.11 

HERF 

500 

1.11 

1.11 

0.00 

1.11 

WSESRB 

750 

0.57 

0.57 

0.00 

0.57 

WSESRB 

750 

0.56 

0.56 

0.00 

0.56 

RADHAZ  Analysis  Lead  Time 

500 

0.55 

0.55 

0.00 

0.55 

EMC  Lead  Time 

500 

10.38 

10.38 

9.84 

0.54 

EMI  Lead  Time 

500 

0.53 

0.53 

0.00 

0.53 

Env  Qual 

1000 

0.53 

0.53 

0.00 

0.53 

ESD  Lead  Time 

500 

0.53 

0.53 

0.00 

0.53 

Bonding  &  Grounding  Lead  Time 

500 

0.52 

0.52 

0.00 

0.52 

RADHAZ  Analysis 

500 

0.44 

0.44 

0.00 

0.44 

EMC(lntra-Sys  EMC) 

500 

0.22 

0.22 

0.00 

0.22 

Start 

500 

0.00 

0.00 

0.00 

0.00 

End 

500 

0.00 

0.00 

0.00 

0.00 

Develop  &  Build 

500 

0.00 

0.00 

0.00 

0.00 

IFC  Lead  Time 

1000 

62.09 

62.09 

62.09 

0.00 

IA  Lead  Time 

500 

20.11 

20.11 

20.11 

0.00 

jrrc 

500 

0.00 

0.00 

0.00 

0.00 

SAASM  HAE  Lead  Time 

500 

0.00 

0.00 

0.00 

0.00 

Wait  until  all  certs  are  done. 

500 

15.92 

15.92 

15.92 

0.00 

Equip  Spectrum  Cert  Lead  Time 

500 

0.00 

0.00 

0.00 

0.00 

Battery  Approval  Lead  Time 

500 

0.00 

0.00 

0.00 

0.00 

Freq  Assignments  Lead  Time 

500 

0.00 

0.00 

0.00 

0.00 

Repeat? 

500 

0.00 

0.00 

0.00 

0.00 

Repeated? 

750 

0.00 

0.00 

0.00 

0.00 

PMA 

3500 

0.00 

0.00 

0.00 

0.00 

jrrc  Lead  Time 

500 

0.00 

0.00 

0.00 

0.00 

Repeated?  w  1 

750 

0.00 

0.00 

0.00 

0.00 

Repeat?  w  1 

500 

0.00 

0.00 

0.00 

0.00 

Collect  Inputs 

500 

0.73 

0.73 

0.73 

0.00 

Collect  HERO  Results 

500 

42.05 

42.05 

42.05 

0.00 

Collect  WSESRB  Results 

500 

0.00 

0.00 

0.00 

0.00 

IA  &  CCA  Finish  Together 

500 

8.24 

8.24 

8.24 

0.00 

WSESRB  Outputs 

500 

0.00 

0.00 

0.00 

0.00 

Finish  Together 

500 

8.08 

8.08 

8.08 

0.00 
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Summary  for  CycleTime  (Wks)  Active  EW  Run  1 IRTR 

Activity  Nante  =  End 


-t — r 


95%  Confidence  Inlcrvali 


•'■‘fccri 


J-v?icri 


53.0 


33.5 


39  jQ 


39.5 


90.5 


91.0 


Andereon-DaHing  Normality  Test 

A-Squared 

QJ2 

P-Value 

0.059 

Mean 

90.21O 

StDev 

12.059 

Variance 

145.424 

Skewness 

0.1O4633 

Kurtosis 

-0.4023O2 

N 

500 

Minimum 

50.461 

1st  Quartile 

01.539 

Median 

09.011 

3rd  Quartile 

99.204 

Maximum 

124.067 

95%  Confidence  Interval  for  Mean 

09.151 

91.270 

95%  Confidence  Interval  for  Median 

00312 

91.236 

95%  Confidence  Interval  for  StDev 

11355 

12.057 

Process  Capability  of  CycleTime  (Wks)  Active  EW  Run  1  IRTR 


Process  Data 

LB 

0 

Target 

52 

USL 

70 

Sample  Mean 

9O.2103 

Sample  N 

500 

StDev(Within) 

12.1215 

StDev(Overalp 

12.0592 

17.5  35.0  52.5  70.0  87.5  105.0  122.5 


Within 
~  ™  Overall 


Potential  (Within)  Capability 

Cp 

* 

CPL 

* 

CPU 

-0.34 

Cpk 

-0.34 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

-034 

Ppk 

-034 

Cpm 

0.22 

Observed  Performance 

%  <  LB 

0.00 

%  >  USL 

03.4O 

%  Total 

03.4O 

Exp,  Within  Performance 
%  <  LB  * 

%  >  USL  S4.31 
%  Total  0431 


Exp.  Overall  Performance 
%  <  LB  * 

%  >  USL  04.44 
%  Total  04.44 
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Probability  Plot  of  CycleTime  (Wks)  Active  EW  Run  1 IRTR 

Normal 


Mean 

9021 

StDev 

12.06 

H 

500 

AD 

0.722 

P-Value 

0.059 
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Active  Electronic  Warfare  (EW)  Run  1 
Low  Risk  Timeline  Reduction  (LRTR) 


284 


RAIN-ActiveEW-Run-1-LRTR_6-29-1 3-hrs.igx 


Elapsed  Time  in  Weeks 

|  38318.92  | 


Transaction  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

500 

76.64 

76.64 

0.00 

76.64 

Activity  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

HERO  Testing  Lead  Time 

500 

29.81 

29.81 

3.82 

25.99 

EMV  Lead  Time 

500 

25.72 

25.72 

0.00 

25.72 

IA  Lead  Time 

500 

25.71 

25.71 

0.00 

25.71 

JITC 

500 

11.66 

11.66 

0.00 

11.66 

Sys  Safety 

500 

10.02 

10.02 

0.00 

10.02 

CCA  Lead  Time 

500 

8.59 

8.59 

0.00 

8.59 

WSESRB  Lead  Time 

750 

8.33 

8.33 

0.00 

8.33 

WSESRB  Lead  Time 

750 

8.30 

8.30 

0.00 

8.30 

HERO  Test  Report 

500 

8.03 

8.03 

0.00 

8.03 

JITC  Lead  Time 

500 

7.87 

7.87 

0.00 

7.87 

Freq  Assignments 

2000 

6.05 

6.05 

0.00 

6.05 

DT 

500 

71.65 

71.65 

66.25 

5.40 

DT  Lead  Time 

500 

4.98 

4.98 

0.00 

4.98 

IA  (Interim) 

500 

3.02 

3.02 

0.00 

3.02 

Range  Safety 

500 

10.14 

10.14 

7.47 

2.68 

Range  Safety  Lead  Time 

500 

61.14 

61.14 

58.47 

2.67 

HERO  Testing 

500 

2.51 

2.51 

0.00 

2.51 

EMV  (Inter-Sys  EMC) 

500 

24.39 

24.39 

21.90 

2.49 

EnvQual  Lead  Time 

500 

2.31 

2.31 

0.00 

2.31 

E3IAR 

4000 

2.23 

2.23 

0.00 

2.23 

E3IAR  Update 

1000 

54.72 

54.72 

52.50 

2.23 

EMI 

500 

2.22 

2.22 

0.00 

2.22 

IFQ 

§00 

1:99 

1:99 

9:99 

1:99 

§00 

1:97 

1:97 

0:00 

1:97 

Minsl@f@un^ins 

§00 

1:11 

1:11 

0:00 

1:11 

HERP 

500 

1.11 

1.11 

0.00 

1.11 

HERO 

500 

1.11 

1.11 

0.00 

1.11 

ESD 

500 

1.11 

1.11 

0.00 

1.11 

HERF 

500 

1.11 

1.11 

0.00 

1.11 

WSESRB 

750 

0.57 

0.57 

0.00 

0.57 

WSESRB 

750 

0.56 

0.56 

0.00 

0.56 

RADHAZ  Analysis  Lead  Time 

500 

0.55 

0.55 

0.00 

0.55 

EMC  Lead  Time 

500 

4.36 

4.36 

3.82 

0.54 

EMI  Lead  Time 

500 

0.53 

0.53 

0.00 

0.53 

EnvQual 

1000 

0.53 

0.53 

0.00 

0.53 

ESD  Lead  Time 

500 

0.53 

0.53 

0.00 

0.53 

Bonding  &  Grounding  Lead  Time 

500 

0.52 

0.52 

0.00 

0.52 

RADHAZ  Analysis 

500 

0.44 

0.44 

0.00 

0.44 

EMC  (Intra-Sys  EMC) 

500 

0.22 

0.22 

0.00 

0.22 

Develop  &  Build 

500 

0.00 

0.00 

0.00 

0.00 

PMA 

3500 

0.00 

0.00 

0.00 

0.00 

Start 

500 

0.00 

0.00 

0.00 

0.00 

Freq  Assignments  Lead  Time 

500 

0.00 

0.00 

0.00 

0.00 

IFC  Lead  Time 

1000 

58.47 

58.47 

58.47 

0.00 

Wait  until  all  certs  are  done. 

500 

47.78 

47.78 

47.78 

0.00 

End 

500 

0.00 

0.00 

0.00 

0.00 

CDL 

1000 

0.00 

0.00 

0.00 

0.00 

Repeat? 

500 

0.00 

0.00 

0.00 

0.00 

Repeated? 

750 

0.00 

0.00 

0.00 

0.00 

Repeated?  wl 

750 

0.00 

0.00 

0.00 

0.00 

Repeat?  wl 

500 

0.00 

0.00 

0.00 

0.00 

Collect  Inputs 

500 

0.73 

0.73 

0.73 

0.00 

Collect  HERO  Results 

500 

36.05 

36.05 

36.05 

0.00 

Collect  WSESRB  Results 

500 

0.00 

0.00 

0.00 

0.00 

lA&CCAFinish  Together 

500 

18.43 

18.43 

18.43 

0.00 

WSESRB  Outputs 

500 

0.00 

0.00 

0.00 

0.00 

Finish  Together 

500 

8.08 

8.08 

8.08 

0.00 
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Summary  for  CycleTime  (Wks)  Active  EW  Run  1  LRTR 


ActivityName  =  End 


T 


95%  Confidence  Intervals 


Anderson-Darling  Normality  Test 

A-Squared 

0.S3 

P-Value 

0,032 

Mean 

76.636 

StDev 

13.373 

Variance 

170.046 

Skewness 

0.373063 

Kurtosis 

0.092144 

N 

500 

Minimum 

44.054 

1st  Quartile 

67.062 

Median 

75.025 

3rd  Quartile 

05.011 

Maximum 

119.304 

96%  Confidence  Interval  for  Mean 

75.463 

77.013 

95%  Confidence  Interval  for  Median 

75.043 

77.156 

95%  Confidence  Interval  for  StDev 

12.593 

14.250 

?5jQ 


75  5 


7b  Q 


77Q 


775 


7SQ 


Process  Capability  of  CycleTime  (Wks)  Active  EW  Run  1  LRTR 


Process  Data 

LB 

0 

Target 

52 

USL 

70 

Sample  Mean 

76.6370 

Sample  N 

500 

StDev(Within) 

13.5503 

StDev(Overalp 

13.3733 

T  *  T  ’  T'T'T  ’■  t  ’■  i 

0  20  40  60  SO  100  120 


Within 
—  —  Overall 


Potential  (Within)  Capability 

Cp 

* 

CPL 

* 

CPU 

0.03 

Cpl< 

0.03 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

0.03 

Ppk 

0.03 

Cpm 

0.31 

Observed  Performance 

%  <  LB 

0.00 

%  >  USL 

42.20 

%  Total 

42.20 

Exp,  Within  Performance 
%  <  LB  * 

%  >  USL  46.00 
%  Total  46.00 


Exp.  Overall  Performance 

%  <  LB 

* 

%  >  USL 

45.94 

%  Total 

45.94 
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Probability  Plot  of  CycleTime  (Wks)  Active  EW  Run  1  LRTR 

Normal 


Mean 

76.64 

StDev 

13.37 

N 

500 

AD 

0.831 

P-Value 

0.032 
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Active  Electronic  Warfare  (EW)  Run  2 
Intermediate  Risk  Timeline  Reduction  (IRTR) 


288 


RAIN-PassiveEW-Run-2-IRTR_6-29-13-hrs.igx 


Elapsed  Time  in  Weeks 

25417.91 


Transaction  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

500 

50.84 

50.84 

0.00 

50.84 

Activity  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

EMV  Lead  Time 

500 

25.72 

25.72 

0.00 

25.72 

Sys  Safety 

500 

10.02 

10.02 

0.00 

10.02 

CCA  Lead  Time 

500 

8.59 

8.59 

0.00 

8.59 

DT 

500 

45.85 

45.85 

40.45 

5.40 

DT  Lead  Time 

500 

4.98 

4.98 

0.00 

4.98 

Range  Safety 

500 

10.14 

10.14 

7.47 

2.68 

Range  Safety  Lead  Time 

500 

2.67 

2.67 

0.00 

2.67 

EMV  (Inter-Sys  EMC) 

500 

2.49 

2.49 

0.00 

2.49 

IA  (Interim) 

500 

2.32 

2.32 

0.00 

2.32 

EnvQual  LaadTIma 

soo 

2.31 

HU 

2.31 

E3IAR 

1500 

2.23 

2.23 

0.00 

2.23 

E3IAR  Update 

1000 

29.68 

29.68 

27.45 

2.23 

EMI 

500 

2.22 

2.22 

0.00 

2.22 

IFC 

500 

1.99 

1.99 

0.00 

1.99 

CCA 

500 

1.97 

1.97 

0.00 

1.97 

EMC  Lead  Time 

500 

0.54 

0.54 

0.00 

0.54 

EMI  Lead  Time 

500 

0.53 

0.53 

0.00 

0.53 

Env  Qual 

500 

0.53 

0.53 

0.00 

0.53 

EMC  (Intra-Sys  EMC) 

500 

0.22 

0.22 

0.00 

0.22 

Develop  &  Build 

500 

0.00 

0.00 

0.00 

0.00 

End 

500 

0.00 

0.00 

0.00 

0.00 

IFC  Lead  Time 

1000 

29.83 

29.83 

29.83 

0.00 

IA  Lead  Time 

500 

0.00 

0.00 

0.00 

0.00 

PMA 

2500 

0.00 

0.00 

0.00 

0.00 

Start 

500 

0.00 

0.00 

0.00 

0.00 

Wait  until  all  certs  are  done. 

500 

40.28 

40.28 

40.28 

0.00 

IA  &  CCA  Finish  Together 

500 

8.24 

8.24 

8.24 

0.00 

Finish  Together 

500 

8.08 

8.08 

8.08 

0.00 
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Summary  for  CycleTime  (Wks)  Active  EW  Run  2 IRTR 

ActivityName  -  End 


95%  Confidence  Intervals 

-  * - m - 4 

■  | - • - 1 

*90 


jq  *a  .m  aa  m  aa 


Anderson-Darling  Normality  Test 

A-Squared 

0.57 

P-Value 

0.140 

Mean 

51.059 

StDev 

11.765 

Variance 

136.695 

Skewness 

0.170011 

Kurtosis 

-0.360474 

N 

500 

Minimum 

25.140 

1st  Quartile 

42.773 

Median 

50.694 

3rd  Quartile 

59.528 

Maximum 

84.568 

95%  Confidence  Internal  for  Mean 

50.024 

52.095 

95%  Confidence  Interval  for  Median 

49.169 

52.238 

95%  Confidence  Interval  for  StDev 

11.097 

12.565 

Process  Capability  of  WorkTime  (Wks)  Active  EW  Run  2  IRTR 


Process  Data 

LB 

0 

Target 

52 

USL 

78 

Sample  Mean 

51.0591 

Sample  N 

500 

StDev(Within) 

11.5483 

StDev(OveralD 

11.7854 

- Within 

—  —  Overall 


Potential  (Within)  Capability 

CP 

CPL 

* 

CPU 

0.78 

0.73 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

0J6 

Ppk 

0.76 

Cpm 

0.73 

Observed  Performance 

%  <  LB 

0.00 

%  >  USL 

1.20 

%  Total 

1.20 

Exp.  Within  Peffioimanoe 
%  <  LB  * 

%  >  USL  0.98 
%  Total  0.96 


Eip.  Overd  Perfomunte 
%  <IB  * 

%  >  USL  1.11 
%  Total  1.11 


~ZT7TT 


Probability  Plot  of  CycleTime  (Wks)  Active  EW  Run  2 IRTR 

Normal 


Mean 

51.06 

StDev 

11.79 

N 

500 

AD 

0.569 

P-Value 

0.140 

291 


Active  Electronic  Warfare  (EW)  Run  2 
Low  Risk  Timeline  Reduction  (LRTR) 


Elapsed  Time  in  Weeks 

I  25746.41  I 


RAIN-ActiveEW-Run-2-LRTR_6-29-13-hrs.igx 


Transaction  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

500 

51.49 

51.49 

0.00 

51.49 

Activity  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

EMV  Lead  Time 

500 

25.72 

25.72 

0.00 

25.72 

IA  Lead  Time 

500 

25.71 

25.71 

0.00 

25.71 

Sys  Safety 

500 

10.02 

10.02 

0.00 

10.02 

CCA  Lead  Time 

500 

8.59 

8.59 

0.00 

8.59 

Freq  Assignments 

1500 

6.05 

6.05 

0.00 

6.05 

DT 

500 

45.86 

45.86 

40.46 

5.40 

DT  Lead  Time 

500 

4.98 

4.98 

0.00 

4.98 

IA  (Interim) 

500 

3.02 

3.02 

0.00 

3.02 

Range  Safety 

500 

10.14 

10.14 

7.47 

2.68 

Range  Safety  Lead  Time 

500 

2.67 

2.67 

0.00 

2.67 

EMV  (Inter-Sys  EMC) 

500 

24.39 

24.39 

21.90 

2.49 

EnvQual  Lead  Time 

500 

2.31 

2.31 

0.00 

2.31 

E3IAR 

2000 

2.23 

2.23 

0.00 

2.23 

E3IAR  Update 

1000 

27.70 

27.70 

25.47 

2.23 

EMI 

500 

2.22 

2.22 

0.00 

2.22 

IFC 

500 

1.99 

1.99 

0.00 

1.99 

CCA 

500 

1.97 

1.97 

0.00 

1.97 

HERP 

500 

1.11 

1.11 

0.00 

1.11 

HERO 

500 

1.11 

1.11 

0.00 

1.11 

HERF 

500 

1.11 

1.11 

0.00 

1.11 

RAD HAZ  Analysis  Lead  Time 

500 

0.55 

0.55 

0.00 

0.55 

EMC  Lead  Time 

500 

4.36 

4.36 

3.82 

0.54 

EMI  Lead  Time 

500 

0.53 

0.53 

0.00 

0.53 

Env  Qual 

500 

0.53 

0.53 

0.00 

0.53 

RADHAZ  Analysis 

500 

0.44 

0.44 

0.00 

0.44 

EMC  (Intra-Sys  EMC) 

500 

0.22 

0.22 

0.00 

0.22 

IFC  Lead  Time 

1000 

29.83 

29.83 

29.83 

0.00 

Freq  Assignments  Lead  Time 

500 

0.00 

0.00 

0.00 

0.00 

Develop  &  Build 

500 

0.00 

0.00 

0.00 

0.00 

End 

500 

0.00 

0.00 

0.00 

0.00 

Wait  until  all  certs  are  done. 

500 

23.29 

23.29 

23.29 

0.00 

PMA 

3000 

0.00 

0.00 

0.00 

0.00 

Start 

500 

0.00 

0.00 

0.00 

0.00 

Collect  HERO  Results 

500 

0.00 

0.00 

0.00 

0.00 

IA&  CCA  Finish  Together 

500 

18.43 

18.43 

18.43 

0.00 

Finish  Together 

500 

8.08 

8.08 

8.08 

0.00 

Summary  for  CycleTime  (Wks)  Active  EW  Run  2  LRTR 


ActivityName  -  End 


^  I  h 


95%  Confidence  Intervals 

I - • - 1 


Andereon-Dariing  Normality  Test 

A-Squared 

0.56 

P-Value 

0.146 

Mean 

51.493 

StDev 

11.412 

Variance 

130.236 

Skewness 

0.17S396 

Kurtosis 

-0.106002 

N 

500 

Minimum 

22.653 

1st  Quartile 

43.147 

Median 

50.920 

3rd  Quartile 

59.520 

Maximum 

04.560 

95%  Confidence  Interval  For  Mean 

50.490 

52.496 

95%  Confidence  Interval  For  Median 

49.756 

52.203 

95%  Confidence  Interval  For  StDev 

10.746 

12.167 

Hsian 


H 


50  JG  5Q.5  510  51.5  520  52.5 


Process  Capability  of  CycleTime  (Wks)  Active  EW  Run  2  LRTR 


“  T  T  T  T  T T  — ' T 

12.5  25.0  37.5  50.0  62.5  75.0 


Process  Data 

LB 

0 

Target 

52 

USL 

70 

Sample  Mean 

51.4920 

Sample  N 

500 

StDev(Within) 

11.3379 

StDev(Overal[) 

11.4121 

Potential  (Within)  Capability 

CP 

* 

CPL 

* 

CPU 

0.70 

Cpk 

0.70 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

0J7 

Ppk 

0.77 

Cpm 

0.76 

Observed  Performance 

Exp,  Within  Performance 

Exp.  Overall  Performance 

%  <  LB 

0.00 

%  <  LB  * 

%  <  LB  * 

%  >  USL 

1.20 

%  >  USL  0.97 

%  >  USL  1.01 

%  Total 

1.20 

%  Total  0,97 

%  Total  1.01 
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Probability  Plot  of  CycleTime  (Wks)  Active  EW  Run  2  LRTR 

Normal 


93,990 


Mean 

51,49 

StDev 

11.41 

N 

500 

AD 

0.561 

P-Value 

0.146 
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Active  Electronic  Warfare  (EW)  Run  3 
Intermediate  Risk  Timeline  Reduction  (IRTR) 


296 


RAIN-ActiveEW-Run-3-IRTR_6-29-13-hrs.igx 


Elapsed  Time  in  Weeks 

12396.22 


Transaction  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

500 

24.79 

24.79 

0.00 

24.79 

Activity  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

Sys  Safety 

500 

10.02 

10.02 

0.00 

10.02 

CCA  Lead  Time 

500 

8.59 

8.59 

0.00 

8.59 

Freq  Assignments 

500 

6.05 

6.05 

0.00 

6.05 

Intrum  Equip  Spectrum  Certt 

500 

6.02 

6.02 

0.00 

6.02 

Range  Safety 

500 

22.12 

22.12 

19.45 

2.68 

Range  Safety  Lead  Time 

500 

2.67 

2.67 

0.00 

2.67 

IA  (Interim) 

500 

HU 

2.32 

He 

2.32 

IFC 

500 

1.99 

1.99 

0.00 

1.99 

CCA 

500 

1.97 

1.97 

0.00 

1.97 

Develop  &  Build 

500 

0.00 

0.00 

0.00 

0.00 

End 

500 

0.00 

0.00 

0.00 

0.00 

IFC  Lead  Time 

1000 

0.00 

0.00 

0.00 

0.00 

IA  Lead  Time 

500 

0.00 

0.00 

0.00 

0.00 

Equip  Spectrum  Cert  Lead  Time 

500 

0.00 

0.00 

0.00 

0.00 

Freq  Assignments  Lead  Time 

500 

0.00 

0.00 

0.00 

0.00 

PMA 

2000 

0.00 

0.00 

0.00 

0.00 

Start 

500 

0.00 

0.00 

0.00 

0.00 

Wait  until  all  certs  are  done. 

500 

14.23 

14.23 

14.23 

0.00 

IA  &  CCA  Finish  Together 

500 

8.24 

8.24 

8.24 

0.00 

Finish  Together 

500 

8.08 

8.08 

8.08 

0.00 

1/1 
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Summary  for  CycleTime  (Wks)  Active  EW  Run  3 IRTR 


ActivityName  =  End 


i  I  > 


95%  Confidence  Intervals 


h 


A 


Anderson-Darling  Normality  Test 

A-Squared 

5.25 

P-Value  < 

0.005 

Mean 

24.792 

StDev 

5.S47 

Variance 

34.190 

Skewness 

0.450020 

Kurtosis 

-0.674584 

N 

500 

Minimum 

12.883 

1st  Quartile 

20.276 

Median 

23.889 

3rd  Quartile 

29.066 

Maximum 

41.412 

95%  Confidence  Internal  for  Mean 

24.279 

25.306 

95%  Confidence  Internal  for  Median 

23.130 

24.438 

95%  Confidence  Interval  for  StDev 

5.506 

6.234 

23.0 


Z5.5 


2*.Q 


2*5 


25  JQ 


255 


Process  Capability  of  CycleTime  (Wks)  Active  EW  Run  3  IRTR 


n —  ^  i  1  r  1  ^  — 1 - 1 - 1 - 1 - 1 - r~ 

□  11  22  33  44  55  66  77 


Process  Data 

LB 

0 

Target 

52 

USL 

78 

Sample  Mean 

24.7924 

Sample  N 

500 

StDev(Within) 

5.77025 

StDev(Overalp 

5.8472 

Potential  (Within)  Capability 

Cp 

* 

CPL 

* 

CPU 

3.07 

Cpk 

3.07 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

3.03 

Ppk 

3.03 

Cpm 

0.31 

Exp.  Within  Performance 

Exp.  Overall  Performance 

%  <  LB 

* 

%  <  LB 

* 

%  >  USL 

0.00 

%  >  USL 

0.00 

%  Total 

0.00 

%  Total 

0.00 

Observed  Performance 

%  <  LB 

0.00 

%  >  USL 

0.00 

%  Total 

0.00 

7W 


Probability  Plot  of  CycleTime  (Wks)  Active  EW  Run  3 IRTR 

Normal 


Mean 

24.79 

StDev 

5.347 

N 

500 

AD 

5.251 

P-Value 

<0.005 
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Active  Electronic  Warfare  (EW)  Run  3 
Low  Risk  Timeline  Reduction  (LRTR) 


300 


RAIN-ActiveEW-Run-3-LRTR_6-29-13-hrs.igx 


Elapsed  Time  in  Weeks 

15096.99 


Transaction  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

500 

30.19 

30.19 

0.00 

30.19 

Activity  Statistics  In  Weeks  (Hours) 


Count 

Avg  Cycle 

Avg  Serv 

Avg  Block 

Avg  Work 

IA  Lead  Time 

500 

25.71 

25.71 

0.00 

25.71 

Sys  Safety 

500 

10.02 

10.02 

0.00 

10.02 

CCA  Lead  Time 

500 

8.59 

8.59 

0.00 

8.59 

Freq  Assignments 

500 

6.05 

6.05 

0.00 

6.05 

IA  (Interim) 

500 

3.02 

3.02 

0.00 

3.02 

Range  Safety 

500 

16.10 

16.10 

13.43 

2.68 

Range  Saf^lless^dlTiiiiiBe 

500 

2.67 

2.67 

0.00 

2.67 

IFC 

500 

1.99 

1.99 

0.00 

1.99 

CCA 

500 

1.97 

1.97 

0.00 

1.97 

Develop  &  Build 

500 

0.00 

0.00 

0.00 

0.00 

End 

500 

0.00 

0.00 

0.00 

0.00 

IFC  Lead  Time 

1000 

0.00 

0.00 

0.00 

0.00 

Freq  Assignments  Lead  Time 

500 

0.00 

0.00 

0.00 

0.00 

PMA 

2000 

0.00 

0.00 

0.00 

0.00 

Start 

500 

0.00 

0.00 

0.00 

0.00 

Wait  until  all  certs  are  done. 

500 

12.76 

12.76 

12.76 

0.00 

IA  &  CCA  Finish  Together 

500 

18.43 

18.43 

18.43 

0.00 

Finish  Together 

500 

8.08 

8.08 

8.08 

0.00 

1/1 
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Summary  for  CycleTime  (Wks)  Active  EW  Run  3  LRTR 


ActivityNarne  =  End 


^ - r 


95%  Confidence  Intervals 

f*fer'i  h  I - « 


Andereon-DaHing  Normality  Test 

A-Squared 

1.71 

P-Value  < 

0.005 

Mean 

30.194 

StDev 

9.220 

Variance 

05.115 

Skewness 

O.3O0005 

Kurtosis 

-0.42033O 

N 

500 

Minimunn 

11.015 

1st  Quartile 

23.041 

Median 

20.954 

3rd  Quartile 

30.003 

Maximum 

54.400 

95%  Confidence  Interval  For  Mean 

29.333 

31.0O5 

95%  Confidence  Interval  For  Median 

20.3O3 

30.207 

95%  Confidence  Interval  For  StDev 

0.007 

9.030 

Mwlrfi 


h 


2a  .Cl  ms  29  JD  29.5  30 .0  3Q.5 


31.0 


Process  Capability  of  CycleTime  (Wks)  Active  EW  Run  3  LRTR 


□  10  20  30  40  50  60  70 


Process  Data 

LB 

0 

Target 

52 

USL 

70 

Sample  Mean 

30.194 

Sample  N 

50O 

StDev(Within) 

9.32597 

StDev(Overal[) 

9.2250 

Potential  (Within)  Capability 

CP 

* 

CPL 

* 

CPU 

1.71 

Cpk 

1.71 

Overall  Capability 

Pp 

* 

PPL 

* 

PPU 

1.73 

Ppk 

1.73 

Cpm 

0.37 

Observed  Performance 

Eip.  Within  Performance 

Eip,  Overall  Performance 

%  ^  LB 

0.00 

%  <  LB  * 

%  <  LB  * 

%  >  USL 

0.00 

%  >  USL  0.00 

%  >  USL  0.00 

%  Total 

0.00 

%  Total  0.00 

%  Total  0.00 
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Probability  Plot  of  CycleTime  (Wks)  Active  EW  Run  3  LRTR 

Normal 


Mean 

30.19 

StDev 

9.226 

N 

500 

AD 

1.709 

P-Value 

<0.005 
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RAIN  Cost  Simulations 


Cost  of  Doing  All  Certifications 
Cost  Matrices  1-3 

LASER  Designator  Runs  1  though  3 

•  Baseline  (BL) 

•  Intermediate  Risk  Timeline  Reduction  (IRTR) 

•  Low  Risk  Timeline  Reduction  (LRTR) 

Passive  EW  Runs  1  though  3 

•  Baseline  (BL) 

•  Intermediate  Risk  Timeline  Reduction  (IRTR) 

•  Low  Risk  Timeline  Reduction  (LRTR) 

Active  EW  Runs  1  though  3 

•  Baseline  (BL) 

•  Intermediate  Risk  Timeline  Reduction  (IRTR) 

•  Low  Risk  Timeline  Reduction  (LRTR) 
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Cost  of  Doing  All  Certifications 
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1  of  3  Cost  Run  Matrices 
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2nd  of  3  Cost  Run  Matrices 
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3rd  of  3  Cost  Run  Matrices 
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LASER  Designator  Run  1 
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LASER  Designator  Run  2 
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LASER  Designator  Run  3 
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Passive  EW  Run  1 
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Passive  EW  Run  2 
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Passive  EW  Run  3 


319 


320 


Active  EW  Run  1 
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Active  EW  Run  2 


rKj  C«tlSnv4rt»f*  AEWft^t  261  ■  tit*  ftnvSof 

r^T^~  ■ „  TT^.  ;JL  ;4  tJ  t3  fc|  C  to  D  f  i'  lTP  ^fe-  -  o  t;  **“  -  Ik  -  I*  ■"  a 


R«J| 

tUrtw  ri  Tub 

io«a 

Utan 

1173 

s.arasTEa 

Stwdarnd  HfrASdn 

24S£2G5 

Vpvnq* 

£1,012  142S 

CwAaert  of  Veruten 

aisoa 

Uunun 

?,I64S£710 

Mnfftfn 

G952£73 

Pler.je 

S.flGS-WM 

3c  WT 

usac 

4J2£73 

i‘5“A:>efcertpe 

USS7S11 

TS'iPercertfr 

1.45*  2*3 

PercerlA^e  Ettw  Pteosori  at  SS“.  Z.wiitenc.'t 

G37B&X 

CkmT^i  Jt 


“3 

A  M«  JUdA 

ZllZ3rf 


Ojn  0vd4ly 
Td» 


:  -.i *J 


YJ^iai 


/  fr  J-.  XAm  C 


CwofcuDon  Fhpa  »Cw* 

Lpgrvg#ntl 
Ftiuj  OH | 

P  Vab*  a  a&y 


•r*  -il  Th*=«tcj 

«***  iatT.it  ijwk 

SaUr  2*5  5£  2€2  E 

SV^r  ff35  Q52 
Kurt  ,02?  059 


3w-w* 

2  J  DwAib 

m 


F -aster 


Da  La  Update  Iritr.  aJ 


F«»r 

Updaw 


►light* 

ftNdhJHrt 


F«BW 

a-'dause. 


Bl&Fifar 

«  *l|  iatp 

Sw  ON?  4K*  **> 

S^Oftl^dri^diin  |  "¥]  *u*4vd  atviitoiS 

SiBih 

u-.n  Mi «  »  eika »i*  it«>  iHflr  I  55j5j  H 
Show  the  Inflowing  s-^eii s t>o?| e >  or  the  hri-togr-er-- 
iMui  V  Mwfijn  □  l^Quoitile  □  3*d  Guarde 

&•>«  0#fem»Ji 

Chart  K  Anu-  4  ~£-  Crfdanoo  4  -!-  Stofeiha  |t  ffr|| 

Cii&tfr/  Cartel 

AfavyiShowV^ndowQhfqp  CteW^II 

Se^orapjr  ert!  VA*n  hKfri*  hkwrazfljil 

tmOm 


323 


SCwt  Wife*  IM I  Uffll  -  ft*  ficratri  ' 


4  :-.  ^  v  >  ;*  ,w  t  M  ;4  fa  fa  fa  C  fa  fa  r  0  \S  »*--  fl  ft  'life  '  -  fli  -  -  "  ° 


Ha-i1  ^-r-1- 


utGqk  Slmuaatitin 

too 


noj 

=y 

in 


fewlti  A£W  Run  2  L  RUL  <  I  MOO  Irl  jUji-  ? 

DO 

t 

Qfl£ 

ooj 

QO 
0 


thh^- 


71 1$ 


T*»  [UA-TbIc  _*] 
OiirtT^  ]@<r 


KAi 
Y*d* 

D«*4utmi  Fnsrfl  -&jr-+ 


ISKSTCi  Cvfti^HI  !GW*J 

7  |  L^jrt  C-^ri«Y  [CbrUXiCUa  _^J 

7  T- 

ii(P:  fruiMm  D  -*-  Cw4if 


X 


FWl 


fav-JW*  1 

vm* 

v#rt#wrt 

KWVi 

IftrWMti 


K^ww 

JAXftfHflfa 

^ tv  99% Ovtdifwt 

Eh&Filta- 

>  SIbw  all  dar.a 


lOCK 

i.OM  iffl 
ICEJ23 
».72i  0J?O 
01^1 
i.$se  ran 
mzm 

i.«T  MC 
DSS6 
0  in  1 
W53*? 
1.171.ES33 
Utift 


£*»w  data  between  ^ 

SNsv  orJy  dafca  Aitfun  P 

SCffrabc 


?l**J  '5  G ' 

f  v*b.  d  i  wr 


iil.-ll  T*i#**ki  «  Cfrnlriudui 

“*■"  1^7  «  W?4  D«f«, 

w"  1(445  ^  a  -- 

Sbtw  &M  OM  J  ' 

Kurt  -gji  055  F±  j 


-H?  ilBf-iwd  ■ir,,iabw<,=l‘ 
Prtiisroti  tarci  Lud  bo  cakxtate  the  «rof  P 


Hj^ktgprvn  RHdjbon 

Fanter  I 

Call  'Jpijoc  Interval 

P«»  EJ 

Jpdll*  ^ 


F«!*r 


95 4J  X 

5ta«-fr0  ioita»-ihfl  vi  dv  Mw*^ 

^  Mcir  ^  Me*sr-  lalGuarfelc 

ia-fcj-.V  C*driP4Jl 

Chart  '  fora.*™  4  :  Stahrtca  4  ' 

Qwplsy  Contd 

f_  Wrtyi ShNfrWbfew £ta T<tf  r  Qawfti  j 

E  SarifcinjfMfli Vlyi  hacfi1*  hVjnrrze  All 


CopyChPt 


324 


Active  EW  Run  3 
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APPENDIX  G.  RISK  ASSESSMENT 


Risk  Simulation  Runs 

Risk  Definitions 

Schedule  Risk 

Impact  =  Max  number  of  weeks  that  the  simulation  predicts  the  schedule  to  exceed  78 
weeks. 

Likelihood  =  %  chance  of  exceeding  78  weeks. 

Cost  Risk 

Impact  =  Max  predicted  cost  minus  the  mean  cost. 

Likelihood  =  Chance  of  cost  exceeding  the  mean  cost. 

Performance  Risk 

Impact  =  From  the  timeline  reduction  scenario  document  for  the  week  of  June  27th  2013 
and  discussions  with  PMA-263  representatives. 

Likelihood  =  Chance  of  impact  occurring  -  TBD  discussions  with  PMA-263 
representatives. 


Certification 

New  Certification  Cycle  Times 

IRTR  (Interim) 

LRTR 

(Already  Have) 

CDL 

No  Change 

0 

IFC 

1,3,2 

1,3,2 

Battery 

1,4,2 

0 

IA 

1,4,2 

No  Change 

Spectrum 

4,8,6  4,8,6 

4,8,6 

T&E 

OT  in  fielding 

Joint  DT  OT 

JTIC 

0 

No  Change 

SAASM 

No  Change 

0 

Table  2:  Timeline  Reduction  Strategies  Sub-P 


rocess  Changes  Summary 
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Laser  Designator  Payload  Run  1 


Chart  size  =  2.3”H  x  3.7”W 


Baseline  LD  R1  Schedule  Risk 
Impact 

=  126  Wks  -  78  Wks 
=  48  Wks 

From  Baseline  Run  1  Simulation 


Summary  for  CycleTime  (Hrs)  Laser  Designator  Run  1 

Activity  Name  =  End 


F 


vY 

/ 


Anderson-Darling  Normality  Test 

A-Squared 

0.66 

P-Value 

0.086 

Mean 

88.532 

StDev 

12.098 

Variance 

146.361 

Skewness 

0.206169 

Kurtosis 

-0.335918 

N 

500 

95<N»  Confidence  Intervals 


Minimum  59.213 

1st  Quartile  79.714 

Median  88.050 

3rd 

Maximum  _ 

sS*fSFffieai 

87.489  89.595 

95%  Confidence  Interval  for  Median 
86.484  89.315 

95%  Confidence  Interval  for  StDev 
11.392 


Baseline  LD  R1  Schedule  Risk 
Likelihood 

=  80.80% 


There  is  a  80.80%  chance  that  the 
schedule  will  exceed  78  weeks  by  as 
much  as  48  weeks. 


Process  Capability  of  CycleTime 


Process  Data 

LSL 

0 

Tjnaau 

■S3- 

USL 

78 

San  ipic  i  >  ici  . 

"86  .b  SSi. 

Sample  N 

500 

StDev(Wilhin) 

12.3478 

StDev(Overall) 

12.098 

-  Within 
■  Overall 


Potential  (Within)  Capability 
Cp  1.05 

CPL  2.39 

CPU  -0.28 

Cpk  -0.28 

Overall  Capability 

Pp 

1.07 

PPL 

2.44 

PPU 

-0.29 

Ppk 

-0.29 

Cpm 

0.23 

0.0  17.5  35.0  52.5  70.0  87.5  105.0  122.5 


Observed  Performance 

Exp.  Within  Performance 

Exp.  Overall  Performance 

%  <  LSL 

0.00 

%  <LSL 

0.00 

%<ISI - 0410 — 

%  >  USL 

79.20 

%  >  USL 

80.32 

%  >  USL  80.80 

Baseline  LD  R1  Cost  Risk  Impact 
=  Max  -  Mean 
=  $2,210K-  $1,32 IK 
=  $889K 


Baseline  LD 
Likelihood 


R1  Cost  Risk 


=  Right  tail  chance  of  exceeding  the 
mean  =  47.58% 


There  is  a  47.58%  chance  that  the 
cost  will  exceed  the  mean  by  $889K. 
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Baseline  LD  R1 
Performance  Risk  Impact 


Increased 


N/A 


Baseline  LD  R1  Increased 
Performance  Risk  Likelihood 


N/A 


Laser  Designator  Payload  Run  2 


Baseline  LD  R2  Schedule  Risk 
Impact 

=  126  Wks  -  78  Wks 
=  48  Wks 


Summary  for  CycleTime  (Hrs)  RAIN  Laser  Designator  Run  2 

ActivityName  =  End 


/ 


j: 


-n 


n 


Anderson-Darling  Normality  Test 

A-Squared 

0.22 

P-Value 

0.841 

Mean 

87.806 

SlDev 

12.952 

Variance 

167.754 

Skewness 

0.041971 

Kurtosis 

-0.330101 

N 

500 

95%  Confidence  Intervals 


Minimum  55.784 

>8.SW" 


Js^SSi 


87.873  


3rd  Quartile  96.515 

Maximum  126.047 


95%  Confidence  Interval  For  Mean 
86.668  88.944 

95%  Confidence  Interval  for  Median 
86.145  89.100 

95%  Confidence  Interval  for  SlDev 
12.196  13.809 


Baseline  LD  R2  Schedule  Risk 
Likelihood 

=  775510  ppm  =  77.55% 


There  is  a  77.55%  chance  that  the 
schedule  will  exceed  78  weeks  by  as 
much  of  48  weeks. 


Process  Capability  of  CycleTime 


Process  Data 

LB 

0 

“us? 

78 

Sample  N 

500 

SlDev(Wilhin) 

13.0913 

SlDev(Overall) 

12.952 

-  Within 
■  Overall 


Potential  (Within)  Capability 
Cp  * 

CPL  * 

CPU  -0.25 
Cpk  -0.25 


Overall  Capability 
Pp  * 

PPL  * 

PPU  -0.25 
Ppk  -0.25 
Cpm  0.23 


0  17.5  35.0  52.5  70.0  87.5  105.0  122.5 


Observed  Performance 

Exp.  Within  Performance 

PPM  <  LB 

0.00 

PPM  <  LB 

* 

PPM  >  USL 

764000.00 

PPM  >  USL 

773090.30 

PPM  Total 

764000.00 

PPM  Total 

773090.30 

Exp.  Overall  Performance 

feu* 


PPM  >  USL  775510.74 

ppm  i  mi  rmurm 
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Baseline  LD  R2  Cost  Risk  Impact 
=  Max  -  Mean 

=  $2,156K-  $  1.265K  =  $89  IK 


Baseline  LD  R2  Cost  Risk 
Likelihood 

=  Right  tail  chance  of  exceeding  the 
mean  =  47.34% 


There  is  a  47.34%  chance  that  the 
cost  will  exceed  the  mean  by  $89 IK. 
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Baseline  LD  R2  Increased 
Performance  Risk  Impact 


N/A 


Baseline  LD  R2  Increased 
Performance  Risk  Likelihood 


N/A 


Laser  Designator  Payload  Run  3 


Baseline  LD  R3  Schedule  Risk 
Impact 

=  65  Wks  -  78  Wks  =  -13  Wks 


Summary  for  CycleTime  (Hrs)  RAIN  LASER  Designator  Run  3 

ActivityName  =  End 


r 


- 


\ 


95%  Confidence  Intervals 


Anderson-Darling  Normality  Test 

A-Squared 

1.47 

P-Value  < 

0.005 

Mean 

43.022 

StDev 

6.695 

Variance 

44.821 

Skewness 

0.331714 

Kurtosis 

-0.234230 

N 

500 

Minimum 

27.237 

1st  Quartile 

38.231 

Median 

42.162 

Maximum 

65.057 

95%  Confidence  Interval  for  Mean 

42.434 

43.610 

95%  Confidence  Interval  for  Median 

41.485 

43.174 

95%  Confidence  Interval  for  StDev 

S.304 

7.138 
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Baseline  LD  R3  Schedule  Risk 
Likelihood 

=  0.000009% 


There  is  a  0.000009%  chance  that  the 
schedule  will  exceed  78  weeks. 


Process  Capability  of  CycleTime  (Hrs)  RAIN  LASER  Designator  Run  3 

'  v  


Process  Data 

LB 

0 

USL 

78 

Sample  N 

500 

StDev(Within) 

6.74358 

StDev(Overal0  6.63484 

ft 


-  Within 
>  Overall 


Potential  (Within)  Capability 
Cp  * 

CPL  * 

CPU  1.73 
Cpk  1.73 


Overall  Capability 
Pp  * 

PPL  * 

PPU  1.74 
Ppk  1.74 
Cpm  0.77 


10  20  30  40  50  60  70 


Observed  Performance 

Exp.  Within  Performance 

Exp,  Overall  Performance 

PPM  <  LB  0.00 

PPM  <  LB  * 

PPM  >  USL  0.00 

PPM  >  USL  0.11 

C  PPM  >  USL  0.03 

PPM  Total  0.00 

PPM  Total  0.11 

>  O:: J  ^  j  i !v: ■  feHrfQ  l£ 


Baseline  LD  R3  Cost  Risk  Impact 
=  Max  -  Mean 
=  $1058K  -  $520K  =  $538K 


^rryw  iHdiTiii  W.iS  »4»ar 


Baseline  LD 
Likelihood 


R3  Cost  Risk 


=  Right  tail  chance  of  exceeding  the 
mean  =  45.44% 


There  is  a  45.44%  chance  that  the 
cost  will  exceed  the  mean  by  $53 8K. 
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Baseline  LD  R3  Increased 
Performance  Risk  Impact 


N/A 


Baseline  LD  R3  Increased 
Performance  Risk  Likelihood 


N/A 


IRTR  Laser  Designator  Run  1 
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Risk  Likelihood 


IRTR  Laser  Designator  Run  2 


IRTR  LD  R2  Schedule  Risk  Impact 
=  85  Wks  -  78  Wks 
=  7  Wks 


Summary  for  CycleTime  (Wks)  LASER  Designator  Run  2  IRTR 

ActivityName  =  End 


r -Pi- 


La 


\n 

\ 


Tn  i  i , 


SO  60  70  SO 


95*N>  Confidence  Intervals 


Anderson-Darling  Normality  Test 
A-Squared  0.36 

P-Value  0.446 


Mean 

StDev 

Variance 

Skewness 

Kuttosis 

N 


50.830 

12.041 

144.331 

0.034760 

-0.317885 

500 


Minimum  22.548 

1st  Quartile  42.723 

Median  50.634 

B^r-n  -riQiE2fc 


Maximum _ 84.568 

35%  Conhdence  Interval  foTMean 
43.832  51.348 

35%  Confidence  Interval  for  Median 
43.163  52.238 

35%  Confidence  Interval  for  StDev 
11.338  12.838 


IRTR  LD  R2  Schedule  Risk 
Likelihood 

=  1.22% 


There  is  a  1.22%  chance  that  the 
schedule  will  exceed  78  weeks  by  as 
much  of  7  weeks. 


Process  Capability  of  CycleTime  (Wks)  LASER  Designator  Run  2  IRTR 


Process  Data 

LB 

0 

-52- 

USL 

Sample  N 

SlDevflAlithin) 

StDev(Overal[) 

500 

11.7531 

12.0412 

-  Within 
>  Overall 


Potential  (Within)  Capability 
Cp  * 

CPL  * 

CPU  0.77 
Cpk  0.77 


Overall  Capability 
Pp  * 

PPL  * 

PPU  0.75 
Ppk  0.75 
Cpm  0.72 


Observed  Performance 

Exp.  Within  Performance 

%  <IB 

0.00 

%  <  LB 

* 

%  >  USL 

1.20 

%  >  USL 

1.06 

%  Total 

1.20 

%  Total 

1.06 

Exp.  Overall  Performance 
f  IR  *  - 


IRTR  LD  R2  Cost  Risk  Impact 
=  Max  -  Mean 
=  $509K  -  $43 7K  =  $72K 

IRTR  LD  R2  Cost  Risk  Likelihood 

=  Right  tail  chance  of  exceeding  the 
mean  =  49.07% 


There  is  a  49.07%  chance  that  the 
cost  will  exceed  the  mean  by  $849K. 
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IRTR  LD  R2  Increased  Performance 
Risk  Impact 


TBD 


IRTR  LD  R2  Increased  Performance 
Risk  Likelihood 


TBD 


IRTR  Laser  Designator  Run  3 


IRTR  LD  R3  Schedule  Risk  Impact 
=  41  Wks-78  Wks 
=  -37  Wks 


Summary  for  CycleTime  (Wks)  LASER  Designator  Run  3  IRTR 

Activity  Name  =  End 


Anderson-Darling  Normality  Test 

A-Squaned 

4.20 

P-Value  < 

0.005 

Mean 

25.387 

StDev 

5.802 

Variance 

33.666 

Skewness 

0.436787 

Kurtosis 

-0.604498 

N 

500 

28  32  36  « 


95%  Confidence  Intervals 


Minimum  14.051 

1st  Quartile  20.763 

Median  24.652 

Maxir 
95%Conl 

24.877  25.897 

95%  Confidence  Interval  for  Median 
24.097  25.234 

95%  Confidence  Interval  for  SlDev 
5.464  6.186 


IRTR  LD  R3  Schedule  Risk 
Likelihood 

=  0.0% 


There  is  a  0%  chance  that  the 
schedule  will  exceed  78  weeks. 


Process  Capability  of  CycleTime  (Wks)  LASER  Designator  Run  3  IRTR 


zzzvsr 

Sample  N  500 
StDev(Wilhin)  5.84716 
StDev(OveralD  5,80223 


- Within 

—  —  Overall 


Potential  (Within)  Capability 
Cp  * 

CPL  * 

CPU  3.00 
Cpk  3.00 


Overall  Capability 
Pp  * 

PPL  * 

PPU  3.02 
Ppk  3.02 
Cpm  0.32 


Observed  Performance 

Exp.  Within  Performance 

Exp.  Overall  Performance 

%  <L£ 

0.00 

%  <L£  * 

%  <L£  * 

%  >  USL 
%  Total 

0.00 

0.00 

%  >  USL  0.00 
%  Total  0.00 

-  Total  0.00 

_ ^ 
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IRTR  LD  R3  Cost  Risk  Impact 
=  Max  -  Mean 
=  $97K  -  $55K  =  $42K 

IRTR  LD  R3  Cost  Risk  Likelihood 

=  Right  tail  chance  of  exceeding  the 
mean  =  49.44% 


There  is  a  49.44%  chance  that  the 
cost  will  exceed  the  mean  by  $42K. 
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IRTR  LD  R3  Increased  Performance 
Risk  Impact 


TBD 


IRTR  LD  R3  Increased  Performance 
Risk  Likelihood 


TBD 


LRTR  Laser  Designator  Run  1 


LRTR  LD  R1  Schedule  Risk  Impact 
=  85  Wks  -  78  Wks 
=  7  Wks 


Summary  for  CycleTime  (Wks)  LASER  Designator  Run  1  LRTR 

ActivityName  =  End 


7 


\ 


95<N»  Confidence  Intervals 


Mean 

Medan 


Anderson-Darling  Normality  Test 

A-Squaned 

1.20 

P-Value  < 

0.005 

Mean 

51.833 

StDev 

10.944 

Variance 

119.775 

Skewness 

0.328759 

Kurtosis 

-0.259609 

N 

500 

Minimum 

26.678 

1st  Quartile 

43.503 

Median 

50.984 

Maximum 

84.568 

95%  Confidence 

Interval  hor  Mean 

50.872 

52.795 

95%  Confidence  Interval  for  Median 

49.838 

52.339 

95%  Confidence  Interval  for  StDev 

10.305 

11.668 
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LRTR  LD  R2  Schedule  Risk  Impact 
=  85  Wks  -  78  Wks 
=  7  Wks 


Summary  for  CycleTime  (Wks)  LASER  Designator  Run  2  LRTR 

ActivityName  =  End 


r 


Anderson-Darling  Normality  Test 

A-Squaned 

0.63 

P-Value 

0.099 

Mean 

51.527 

StDev 

11.354 

Variance 

128.924 

Skewness 

0.200197 

Kurtosis 

-0.205535 

N 

500 

«o  so 


70  80 


95<N>  Confidence  Intervals 


Minimum  22 .653 

1st  Quartile  43.147 

Median  50.928 


Maximum 


84.568 


95%  Confidence  IritervaTFor  Mean 

50.529  52.525 

95%  Confidence  Interval  for  Median 
49.756  52.283 

95%  Confidence  Interval  for  StDev 
10.692  12.106 


LRTR  LD  R2  Schedule  Risk 
Likelihood 

=  0.99% 


There  is  a  0.99%  chance  that  the 
schedule  will  exceed  78  weeks  by  as 
much  of  7  weeks. 


Process  Capability  of  CycleTime  (Wks)  LASER  Designator  Run  2  LRTR 


Process  Data 

LB 

0 

Target - - ^  

j  USL 

78 

JJIlipte'Mew- 

Sample  N 

500 

StDev(Within) 

11.2818 

StDev(Overall) 

11.3545 

-  Within 
■  Overall 


Potential  (Within)  Capability 
Cp  * 

CPL  * 

CPU  0.78 
Cpk  0.78 


Overall  Capability 
Pp  * 

PPL  * 

PPU  0.78 
Ppk  0.78 
Cpm  0.76 


0.0  12.5  25.0  37.5  50.0  62.5  75.0 


Observed  Performance 

Exp.  Within  Performance 

II  Exp.  Overall  Performance  | 

%  <  LB 

0.00 

%  <  LB  * 

^6  -clLB - * 

%  >  USL 

1.20 

1.20 

%  >  USL  0.95 
%  Total  0.95 

%  >  USL  0.99 

%  Total 
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LRTR  LD  R2  Cost  Risk  Impact 
=  Max  Mean 

=  $1687K  -  $1,035K  =  $652K 

LRTR  LD  R2  Cost  Risk  Likelihood 

=  Right  tail  chance  of  exceeding  the 
mean  =  46.60% 


There  is  a  46.60%  chance  that  the 
cost  will  exceed  the  mean  by  $652K. 
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LRTR  LD  R2  Increased  Performance 
Risk  Impact 


TBD 


LRTR  LD  R2  Increased  Performance 


TBD 
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Risk  Likelihood 


LRTR  Laser  Designator  Run  3 


LRTR  LD  R3  Schedule  Risk  Impact 
=  54  Wks  -  78  Wks 
=  -24  Wks 


Summary  for  CycleTime  (Wks)  LASER  Designator  Run  3  LRTR 

ActivityName  =  End 


ll  :  L 


95<N>  Confidence  Intervals 


Anderson-Darling  Normality  Test 

A-Squaned 

1.89 

P-Value  < 

0.005 

Mean 

32.137 

StDev 

7.996 

Variance 

63.935 

Skewness 

0.387973 

Kurtosis 

-0.354624 

N 

500 

Minimum 

15.513 

1st  Quartile 

25.704 

Median 

31.630 

Maximum 

54.400 

95%  Confidence 

Interval  for  Mean 

31.435 

32.840 

95%  Confidence  Interval  for  Median 

30.640 

32.606 

95%  Confidence  Interval  for  StDev 

7.529 

8.525 

Schedule  Risk 


LRTR  LD  R3 
Likelihood 

=  0.0% 


There  is  a  0%  chance  that  the 
schedule  will  exceed  78  weeks  by  as 
much  of  48  weeks. 


Process  Capability  of  CycleTime  (Wks)  LASER  Designator  Run  3  LRTR 

Target 


Process  Data 

LB 

0 

-52 — 

USL 

Sample  N 

StDevflAlithin) 

StDev(Overal[) 

500 

8.12186 

7.99594 

-  Within 
>  Overall 


Potential  (Within)  Capability 
Cp  * 

CPL  * 

CPU  1.88 
Cpk  1.88 


Overall  Capability 
Pp  * 

PPL  * 

PPU  1.91 
Ppk  1.91 
Cpm  0.40 


Observed  Performance 

Exp.  Within  Performance 

Exp.  Overall  Performance 

%  <IB 

0.00 

%  <  LB  * 

,  .jyj-  -  - — 

%  >  USL 

0.00 

%  >  USL  0.00  < 

%  >  USL  0.00 

%  Total 

0.00 

%  Total  0.00 

C-K+'i-FT,  ’• 


LRTR  LD  R3  Cost  Risk  Impact 
=  Max  -  Mean 
=  $568K  -  $287K  =  $281K 

LRTR  LD  R3  Cost  Risk  Likelihood 

=  Right  tail  chance  of  exceeding  the 
mean  =  45.51% 


There  is  a  45.51%  chance  that  the 
cost  will  exceed  the  mean  by  $28 IK. 
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LRTR  LD  R3  Increased  Performance 
Risk  Impact 


TBD 


LRTR  LD  R3  Increased  Performance 
Risk  Likelihood 


TBD 


Passive  EW  Run  1 


Baseline  Passive  EW  R1  Schedule 
Risk  Impact 

=  241  Wks  -  78  Wks  =  163  Wks 


Summary  for  CycleTime  (Hrs)  RAIN  Passive  EW  Run  1 

ActivityName  =  End 


V 


r 


H 


M 


95<N>  Confidence  Intervals 


Anderson-DaHing  Normality  Test 

A-Squared 

0.36 

P-Value 

0.438 

Mean 

180.24 

StDev 

15.85 

Variance 

251.15 

Skewness 

0.218344 

Kurtosis 

0.241126 

N 

500 

Minimum 

136.98 

1st  Quartile 

168.89 

Median 

180.67 

Maximum 

241.25 

95%  Confidence 

Interval  for  Mean 

178.85 

181.63 

95%  Confidence  Interval  for  Median 

178.37 

182.45 

95%  Confidence  Interval  for  StDev 

14.92 

16.90 

Baseline  Passive  EW  R1  Schedule 
Risk  Likelihood 

=  1000000.00  PPM  =  100% 


There  is  a  100%  chance  that  the 
schedule  will  exceed  78  weeks. 


Process  Capability  of  CycleTime  (Hrs)  RAIN  Passive  EW  Run  1 


Process  Data 

LB 

0 

-G2 - 

USL 

78 

Sample  N 

500 

StDev(Wilhin) 

16.1491 

StDev(Overal0 

15.8479 

—  Within 
—  —  Overall 


Potential  (Within)  Capability 
Cp  * 

CPL  * 

CPU  -2.11 
Cpk  -2.11 


Overall  Capability 
Pp  * 

PPL  * 

PPU  -2.15 
Ppk  -2.15 
Cpm  0.07 


1D5  140  175  210  245 


Observed  Performance 
PPM  <  LB  0.00 

PPM  >  USL  1000000.00 
PPM  Total  1000000.00 


Exp.  Within  Performance 
PPM  <  IB  * 

PPM  >  USL  1000000.00 
PPM  Total  1000000.00 


Exp.  Overall  Performance 

m 


PPM  >  USL  1000000.00 

ppsrrair 


1000.00  3 

IUUU.00 
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Baseline  Passive  EW  R1  Cost  Risk 
Impact 

=  Max  -  Mean 

=  $2,6 17K  -  $1,723K  =  $894K 


Baseline  Passive  EW  R1  Cost  Risk 
Likelihood 

=  Right  tail  chance  of  exceeding  the 
mean  =  47.74% 


There  is  a  47.74%  chance  that  the 
cost  will  exceed  the  mean  by  $894K. 
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Baseline  Passive  EW  R1  Increased 
Performance  Risk  Impact 


N/A 


Baseline  Passive  EW  R1  Increased 
Performance  Risk  Likelihood 


N/A 


Passive  EW  Run  2 


Baseline  Passive  EW  R2  Schedule 
Risk  Impact 

=  126  Wks  -  78  Wks  =  48  Wks 


Summary  for  CycleTime(Hrs)  RAIN  Passive  EW  Run  2 

ActivityName  =  End 


/-f 


j^rPT 


\ 


N  n 


60  70  ao 


95%  Confidence  Intervals 


Anderson-Darling  Normality  Test 

A-Squaned 

0.18 

P-Value 

0.914 

Mean 

87.752 

StDev 

13.041 

Variance 

170.055 

Skewness 

0.017197 

Kuttosis 

-0.308535 

N 

500 

Minimum 

54.079 

1st  Quattile 

78.476 

Median 

87.673 

C  Maximum 

126.047 

95%  Confidence  Interval  for  Mean 

86.606 

88.898 

95%  Confidence  Interval  for  Median 

86.145 

89.100 

95%  Confidence  Interval  for  StDev 

12.279 

13.903 
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Baseline  Passive  EW  R2  Schedule 
Risk  Likelihood 

=  77.27% 


There  is  a  77.27%  chance  that  the 
schedule  will  exceed  78  weeks. 


Process  Capability  of  CycleTime 


Target  USL 


Process  Data 

LB  0 

USL 

78  - 

Sample  N 

500 

StDev(Within) 

13.1686 

StDev(Overal0 

13.0405 

-  Within 
>  Overall 


Potential  (Within)  Capability 
Cp  * 

CPL  * 

CPU  -0.25 
Cpk  -0.25 


Overall  Capability 
Pp  * 

PPL  * 

PPU  -0.25 
Ppk  -0.25 
Cpm  0.23 


0.0  17.5  35.0  52.5  70.0  87.5  105.0  122.5 


Observed  Performance 

Exp.  Within  Performance 

Exp,  Overall  Performance 

%  <  IB  0.00 

%  <  LB  * 

^  -lp  * 

%  >  USL  76.20 

%  >  USL  77.05  < 

%  >  USL  77.27 

%  Total  76.20 

%  Total  77.05 

■■■ 


Baseline  Passive  EW  R2  Cost  Risk 
Impact 

=  Max  -  Mean 

=  $2,124K-  $1,231K  =  $893K 


Baseline  Passive  EW  R2  Cost  Risk 
Likelihood 

=  Right  tail  chance  of  exceeding  the 
mean  =  47.72% 


There  is  a  47.72%  chance  that  the 
cost  will  exceed  the  mean  by  $893K. 
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Baseline  Passive  EW  R2  Increased 
Performance  Risk  Impact 


N/A 


Baseline  Passive  EW  R2  Increased 
Performance  Risk  Likelihood 


N/A 


Passive  EW  Run  3 
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Baseline  Passive  EW  R3  Schedule 
Risk  Impact 

=  54  Wks  -  78  =  -24  Wks 


Summary  for  CycleTime  (Hrs)  RAIN  Passive  EW  Run  3 

ActivityName  =  End 


-  N 


T| 


ffll 


24  30  36  42  48  54 


95^6  Confidence  Intervals 


Anderson-Darling  Normality  Test 
A-Squared  1.15 

P-Value  0.005 

Mean 

34.277 

StDev 

7.590 

Variance 

57.614 

Skewness 

0.237583 

Kurtosis 

-0.484966 

N 

500 

Minimum 

15.609 

1st  Quartile 

28.757 

Median 

33.614 

Maximum 

54.400 

95%  Confidence  Interval  for  Mean 

33.611 

34.944 

95%  Confidence  Interval  for  Median 

32.863 

34.576 

95%  Confidence  Interval  for  StDev 

7.147 

8.092 

Baseline  Passive  EW  R3  Schedule 
Risk  Likelihood 

=  0.0% 


There  is  a  0%  chance  that  the 
schedule  will  exceed  78  weeks. 


Process  Capability  of  CycleTime  (Hrs)  RAIN  Passive  EW  Run  3 


I  |USL 


-  Within 
■  Overall 


Potential  (Within)  Capability 
Cp  * 

CPL  * 

CPU  1.92 
Cpk  1.92 


Overall  Capability 
Pp  * 

PPL  * 

PPU  1.92 
Ppk  1.92 
Cpm  0.45 


10  20  30  40  50  60  70 


Observed  Performance 

Exp.  Within  Performance 

Exp.  Overall  Performance 

PPM  <  LB  0.00 

PPM  <  LB  * 

pnrui^io  * 

PPM  >  USL  0.00 

PPM  >  USL  0.00  < 

PPM  >  USL  0.00 

2 

PPM  Total  0.00 

PPM  Total  0.00 

-'.zmA  li-rr-j  4<  c»  i  iW  4ji  Jtt  4  <iij  i-.;.-  Ima:l 
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Baseline  Passive  EW  R3  Cost  Risk 
Impact 

=  Max  Mean 

=  $1058K  -  $520K  =  $538K 


Baseline  Passive  EW  R3  Cost  Risk 
Likelihood 

=  Right  tail  chance  of  exceeding  the 
mean  =  45.44% 


There  is  a  45.44%  chance  that  the 
cost  will  exceed  the  mean  by  $53 8K. 
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Baseline  Passive  EW  R3  Increased 
Performance  Risk  Impact 


N/A 
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IRTR  PEW  R1  Cost  Risk  Impact 
=  Max  -  Mean 

=  $1,689K-  $  1.230K  =  $459K 

IRTR  PEW  R1  Cost  Risk  Likelihood 

=  Right  tail  chance  of  exceeding  the 
mean  =  45.10% 


There  is  a  45.10%  chance  that  the 
cost  will  exceed  the  mean  by  $459K. 
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IRTR  PEW  R1  Increased 
Performance  Risk  Impact 


TBD 


IRTR  PEW  R1  Increased 
Performance  Risk  Likelihood 


TBD 


IRTR  Passive  EW  Run  2 


IRTR  PEW  R2  Schedule  Risk 
Impact 

=  85  Wks  -  78  Wks 
=  7  Wks 


Summary  for  CycleTime  (Wks)  Passive  EW  Run  2  IRTR 

ActivityName  =  End 


95<N>  Confidence  Intervals 


Anderson-Darling  Normality  Test 
A-Squared  0.30 

P-Value  0.583 


Mean 

StDev 

Variance 

Skewness 

Kurtosis 

N 


50.838 

12.135 

147.265 

0.062106 

-0.281635 

500 


Minimum  20.066 

1st  Quartile  42.723 
Median  50.634 

V  7- —nil  nr  nit 

_  Maximum _ 84.568  .  ; 

95%  Confidence  Interval  For  Mean 
49.770  51.902 

95%  Confidence  Interval  For  Median 
49.169  52.238 

95%  Confidence  Interval  for  StDev 
11.427  12.938 
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IRTR  PEW  R2  Schedule  Risk 


Process  Capability  of  CycleTime  (Wks)  Passive  EW  Run  2  IRTR 


Likelihood 
=  1.26% 


There  is  a  1.26%  chance  that  the 
schedule  will  exceed  78  weeks  by  as 
much  of  48  weeks. 


Observed  Performance 

Exp.  Within  Performance 

Exp.  Overall  Performance 

%  <  LB  0.00 

%  <L£  * 

%  >  USL  1.20 

%  >  USL  1.09  ^ 

%  >  USL  1.28 

%  Total  1.20 

%  Total  1.09 

IRTR  PEW  R2  Cost  Risk  Impact 
=  Max  Mean 
=  $1,239K  -  $784K  =  $455K 

IRTR  PEW  R2  Cost  Risk  Likelihood 

=  Right  tail  chance  of  exceeding  the 
mean  =  45.18% 


There  is  a  45.18%  chance  that  the 
cost  will  exceed  the  mean  by  $45 5K. 


IRTR  PEW  R2 


Increased 


TBD 


Performance  Risk  Impact 
IRTR  PEW  R2 


Increased 


TBD 


Performance  Risk  Likelihood 


IRTR  Passive  EW  Run  3 
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Performance  Risk  Likelihood 


LRTR  Passive  EW  Run  1 


LRTR  PEW  R1  Schedule  Risk 
Impact 

=  119  Wks  -  78  Wks 
=  41  Wks 


Summary  for  CycleTime  (Wks)  Passive  EW  Run  1  LRTR 

ActivityName  =  End 


Anderson-Darling  Normality  Test 

A-Squared 

0.83 

P-Value 

0.032 

Mean 

76.638 

StDev 

13.373 

Variance 

178.846 

Skewness 

0.373863 

Kurtosis 

0.092144 

N 

500 

95<N>  Confidence  Intervals 


Minimum  44.054 

rai r- 


b/.Ub^ 

75.825 


3rd  Quartile  85.011 

Maximum  118.304 


95%  Confidence  Interval  for  Mean 
75.463  77.813 

95%  Confidence  Interval  for  Median 
75.043  77.156 

95%  Confidence  Interval  for  StDev 
12.593  14.258 


LRTR  PEW  R1 
Likelihood 

=  45.94% 


Schedule  Risk 


There  is  a  45.94%  chance  that  the 
schedule  will  exceed  78  weeks  by  as 
much  of  41  weeks. 


Process  Capability  of  WorkTime  (Wks)  Passive  EW  Run  1  LRTR 


Process  Data 

LB 

0 

USL 

78 

Sample  N 

500 

StDev(Within) 

13.5583 

SlDev(Overall) 

13.3733 

-  Within 
■  Overall 


Potential  (Within)  Capability 
Cp  * 

CPL  * 

CPU  0.03 
Cpk  0.03 


Overall  Capability 
Pp  * 

PPL  * 

PPU  0.03 
Ppk  0.03 
Cpm  0.31 


Observed  Performance 

Exp.  Within  Performance 

%  <  LB 

0.00 

%  <  LB 

* 

%  >  USL 

42.20 

%  >  USL 

46.00  ^ 

%  Total 

42.20 

%  Total 

Exp.  Overall  Performance 

JUlfi- 
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LRTR  PEW  R1  Cost  Risk  Impact 
=  Max  -  Mean 

=  $2,040K-  $  1.385K  =  $655K 


LRTR  PEW  R1  Cost  Risk 
Likelihood 

=  Right  tail  chance  of  exceeding  the 
mean  =  46.69% 


There  is  a  46.69%  chance  that  the 
cost  will  exceed  the  mean  by  $655K. 
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LRTR  PEW  R1  Increased 
Performance  Risk  Impact 


TBD 


LRTR  PEW  R1  Increased 
Performance  Risk  Likelihood 


TBD 


LRTR  Passive  EW  Run  2 


LRTR  PEW  R2  Schedule  Risk 
Impact 

=  85  Wks  -  78  Wks 
=  7  Wks 


Summary  for  CycleTime  (Wks)  Passive  EW  Run  2  LRTR 

ActivityName  =  End 


rfrff. 


FFn 


\ 


Anderson-DaHing  Normality  Test 

A-Squared 

0.56 

P-Value 

0.148 

Mean 

51.491 

StDev 

11.414 

Variance 

130.283 

Skewness 

0.178151 

Kurtosis 

-0.187652 

N 

500 

to  ao 


95°o  Confidence  Intervals 


Minimum  22.653 

1st  Quartile  43,147 
Median  50.928 

Maximum 

9596  Confidence  interval  For  Mean 
50.488  52.494 

95%  Confidence  Interval  For  Median 
49.756  52.283 

95%  Confidence  Interval  For  SlDev 
10.748  12.169 
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LRTR  PEW  R2  Schedule  Risk 
Likelihood 

=  1.01% 


There  is  a  1.01%  chance  that  the 
schedule  will  exceed  78  weeks  by  as 
much  of  7  weeks. 


LRTR  PEW  R2  Cost  Risk  Impact 
=  Max  Mean 

=  $  1 ,674K  -  $  1 ,020K  =  $654K 


LRTR  PEW  R2  Cost  Risk 
Likelihood 

=  Right  tail  chance  of  exceeding  the 
mean  =  46.59% 


There  is  a  46.59%  chance  that  the 
cost  will  exceed  the  mean  by  $654K. 


Process  Capability  of  CycleTime  (Wks)  Passive  EW  Run  2  LRTR 


Process  Data 

LB 

0 

USL 

78 

Sample  N 

SlDev(Within) 

StDev(Overalf) 

500 

11.3383 

11.4142 

-  Within 
>  Overall 


Potential  (Within)  Capability 
Cp  * 

CPL  * 

CPU  0.78 
Cpk  0.78 


Overall  Capability 
Pp  * 

PPL  * 

PPU  0.77 
Ppk  0.77 
Cpm  0.78 


0.0  12.5  25.0  37.5  50.0  62.5  75.0 


Observed  Performance 

Exp.  Within  Performance 

Exp.  Overall  Performance 

%  <  LB  0.00 

%  <IB  * 

* 

%  >  USL  1.20 

%  >  USL  0.97  ^ 

a/  .  1  ft  ft -7 

%  >  USL  1.01 

%  Total  1.20 

%  Total  0.S7 
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LRTR  PEW  R2  Increased 
Performance  Risk  Impact 


TBD 


LRTR  PEW  R2  Increased 
Performance  Risk  Likelihood 


TBD 


LRTR  Passive  EW  Run  3 
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Performance  Risk  Likelihood 


Active  EW  Run  1 


Baseline  Active  EW  R1  Schedule 
Risk  Impact 

=  241  Wks  -  78  Wks  =  163  Wks 


Summary  for  CycleTime  (Hrs)  RAIN  Active  EW  Run  1 

ActivityName  =  End 


FT 


/ 


h 


\i 


CEk. 


Anderson-DaHing  Normality  Test 

A-Squared 

0.36 

P-Value 

0.438 

Mean 

180.24 

StDev 

15.85 

Variance 

251.15 

Skewness 

0.218344 

Kurtosis 

0.241126 

N 

500 

95*?i>  Confidence  Intervals 


Minimum  136.98 
1st  Quartile  168.89 
Median  180.67 

Jrrl^ 

Maximum _ 241.25 

95%  Confidence  THFervaUw  Mean 
178.85  181.63 

95%  Confidence  Interval  for  Median 
178.37  182.45 

95%  Confidence  Interval  for  StDev 
14.92  16.90 


Baseline  Active  EW  R1  Schedule 
Risk  Likelihood 

=  1000000.00  PPM  =  100% 


There  is  a  100%  chance  that  the 
schedule  will  exceed  78  weeks. 


Process  Capability  of  CycleTime  (Hrs)  RAIN  Active  EW  Run  1 


LB 

0 

USL 

78 

Sample  N 

500 

StDev(Wilhin) 

16.1491 

StDev(Overalfl 

15.8479 

—  Within 
—  —  Overall 


Potential  (Within)  Capability 
Cp  * 

CPL  * 

CPU  -2.11 
Cpk  -2.11 


Overall  Capability 
Pp  * 

PPL  * 

PPU  -2.15 
Ppk  -2.15 
Cpm  0.07 


105  140  175  210  245 


Observed  Performance 
PPM  <  LB  0.00 

PPM  >  USL  1000000.00 
PPM  Total  1000000.00 


Exp.  Within  Performance 
PPM  <  LB 
PPM  >  USL  1000000 .0( 
PPM  Total  1000000.00 


Exp.  Overall  Performance 

*  PDW 

10  .PPN 


PPM  >  USL  1000000.00 

PPM  lotai  iuuuuuu.00 
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Baseline  Active  EW  R1  Cost  Risk 
Impact 

=  Max  -  Mean 

=  $2,6 17K  -  $1,723K  =  $894K 


Baseline  Active  EW  R1  Cost  Risk 
Likelihood 

=  Right  tail  chance  of  exceeding  the 
mean  =  47.74% 


There  is  a  47.74%  chance  that  the 
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cost  will  exceed  the  mean  by  $894K. 


Baseline  Active  EW  R1  Increased 
Performance  Risk  Impact 


N/A 


Baseline  Active  EW  R1  Increased 
Performance  Risk  Likelihood 


N/A 


Active  EW  Run  2 


Baseline  Active  EW  R2  Schedule 
Risk  Impact 

=  163  Wks  -  78  Wks  =  85  Wks 


Summary  for  CycleTime  (Hrs)  RAIN  Active  EW  Run  2 

ActivityName  =  End 


FE 


110  120  130  HO  150  160 


95<N>  Confidence  Intervals 


Anderson-Darling  Normality  Test 

A-Squared 

P-Value 

0.36 

0.436 

Mean 

132.86 

StDev 

10.02 

Variance 

100.48 

Skewness 

0.0658247 

Kuitosis 

0.0047435 

N 

500 

Minimum 

102.14 

1st  Quartile 
Median 

126.32 

132.61 

Maximum 

85%  Confidence 

Interval  for  Mean 

131.87 

133.74 

85%  Confidence  Interval  for  Median 

131.48 

133.57 

85%  Confidence  Interval  for  StDev 

8.44 

10.68 

Baseline  Active 
Risk  Likelihood 


EW  R2  Schedule 


=  999999.98  PPM  =  99.99% 


There  is  a  99.99%  chance  that  the 
schedule  will  exceed  78  weeks. 


Process  Capability  of  CycleTime  (Hrs)  RAIN  Active  EW  Run  2 


Process  Data 

LB 

0 

USL 

78 

Sample  N 

500 

StDev(Within) 

10.3068 

StDev(Overall) 

10.024 

-  Within 
■  Overall 


Potential  (Within)  Capability 
Cp  * 

CPL  * 

CPU  -1.77 
Cpk  -1.77 


Overall  Capability 
Pp  * 

PPL  * 

PPU  -1.82 
Ppk  -1.82 
Cpm  0.11 


0.0  22.5  45.0  67.5  90.0  112.5  135.0  157.5 


Observed  Performance 

Exp.  Within  Performance 

Exp.  Overall  Performance 

PPM  <  LB  0.00 

PPM  <  LB  * 

PPM  f * 

PPM  >  USL  1000000.00 

PPM  >  USL  383338.85  i 

PPM  >  USL  333333.88 

PPM  Total  1000000.00 

PPM  Total  333338.35 
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Baseline  Active  EW  R2  Cost  Risk 
Impact 

=  Max  -  Mean 

=  $2,183K  -  $1,285K  =  $898K 


Baseline  Active  EW  R2  Cost  Risk 
Likelihood 


=  Right  tail  chance  of  exceeding  the 
mean  =  47.51% 


There  is  a  47.51%  chance  that  the 
cost  will  exceed  the  mean  by  $898K. 
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Baseline  Active  EW  R2  Increased 
Performance  Risk  Impact 


N/A 


Baseline  Active  EW  R2  Increased 
Performance  Risk  Likelihood 


N/A 


Active  EW  Run  3 


Baseline  Active  EW  R3  Schedule 
Risk  Impact 

=  133  Wks  -  78  Wks  =  55  Wks 


Summary  for  CycleTime  (Hrs)  RAIN  Active  EW  Run  3 

ActivityName  =  End 


/ 


- 


Ik 


\ 


100  110  120  130 


95<N>  Confidence  Intervals 


Mean 

Medan 


Anderson-Darling  Normality  Test 

A-Squared 

0.77 

P-Value 

0.048 

Mean 

102.44 

StDev 

9.58 

Variance 

91.49 

Skewness 

0.101192 

Kuttosis 

•0.010388 

N 

500 

Minimum 

73.98 

1st  Quartile 

95.73 

Median 

101.57 

Maximum 

133.24 

95%  Confidence 

Interval  for  Mean 

101.80 

103.28 

95%  Confidence  Interval  for  Median 

100.58 

102.91 

95%  Confidence  Interval  for  StDev 

9.01 

10.20 
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Baseline  Active 
Risk  Likelihood 


EW  R3  Schedule 


:  994685.85  PPM  =  99.47% 


There  is  a  99.47%  chance  that  the 
schedule  will  exceed  78  weeks. 


Process  Capability  of  CycleTime  (Hrs)  RAIN  Active  EW  Run  3 


Process  Data 

LB 

0 

USL 

78 

Sample  N 

SlDev(Within) 

StDev(OveralD 

500 

9.87903 

9.58498 

-  Within 
>  Overall 


Potential  (Within)  Capability 
Cp  * 

CPL  * 

CPU  -0.82 
Cpk  -0.82 


Overall  Capability 
Pp  * 

PPL  * 

PPU  -0.85 
Ppk  -0.85 
Cpm  0.17 


0.0  17.5  35.0  52.5  70.0  87.5  105.0  122.5 


Observed  Performance 

Exp,  Within  Performance 

Exp.  Overall  Performance 

PPM  <  LB 

0.00 

PPM  <  LB 

PPM  * 

PPM  >  USL 

992000.00 

PPM  >  USL 

993309.67 

PPM  >  USL  994685.85 

PPM  Total 

992000.00 

PPM  Total 

993309.67 
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Baseline  Active  EW  R3  Cost  Risk 
Impact 

=  Max  -  Mean 

=  $1069K  -  $530K  =  $539K 


Baseline  Active  EW  R3  Cost  Risk 
Likelihood 

=  Right  tail  chance  of  exceeding  the 
mean  =  45.47% 


There  is  a  45.47%  chance  that  the 
cost  will  exceed  the  mean  by  $539K. 
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Baseline  Active  EW  R3  Increased 
Performance  Risk  Impact 


N/A 


Baseline  Active  EW  R3  Increased 
Performance  Risk  Likelihood 


N/A 


IRTR  Active  EW  Run  1 


IRTR  AEW  R1  Schedule  Risk  Impact 
=  124  Wks  -  78  Wks 
=  46  Wks 


354 


355 


IRTR  AEW  R1  Increased  Performance  Risk 
Likelihood 


TBD 


IRTR  Active  EW  Run  2 


IRTR  AEW  R2  Schedule  Risk 
Impact 

=  85  Wks  -  78  Wks 
=  7  Wks 


Summary  for  CycleTime  (Wks)  Active  EW  Run  2  IRTR 

ActivityName  =  End 


/  - 


\ 


Anderson-Darling  Normality  Test 

A-Squared 

0.57 

P-Value 

0.140 

Mean 

51.059 

StDev 

11.785 

Variance 

138.895 

Skewness 

0.170011 

Kurtosis 

-0.360474 

N 

500 

40  SO  60  70 


95%  Confidence  Intervals 


95%  Confidence  Interval  For  Mean 
50.024  52.095 

95%  Confidence  Interval  For  Median 
49.169  52.238 

95%  Confidence  Interval  For  StDev 
11.097  12.565 


IRTR  AEW  R2  Schedule  Risk 
Likelihood 

=  1.11% 


There  is  a  1.11%  chance  that  the 
schedule  will  exceed  78  weeks  by  as 
much  of  7  weeks. 


Process  Capability  of  WorkTime  (Wks)  Active  EW  Run  2  IRTR 


Observed  Performance 

Exp.  Within  Performance 
%  <LB  * 

%  <  LB 

0.00 

%  >  USL 

1.20 

%  >  USL  0.98 

%  Total 

1.20 

%  Total  0.98 

Exp.  Overall  Performance 

%  >  USL  1.11 
%  Total  1.11 


IRTR  AEW  R2  Cost  Risk  Impact 
=  Max  -  Mean 
=  $1297K-  $815K  =  $482K 

IRTR  AEW  R2  Cost  Risk  Likelihood 

=  Right  tail  chance  of  exceeding  the 
mean  =  44.36% 


There  is  a  44.36%  chance  that  the 
cost  will  exceed  the  mean  by  $482K. 
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IRTR  AEW  R2  Increased 
Performance  Risk  Impact 


TBD 


IRTR  AEW  R2  Increased 
Performance  Risk  Likelihood 


TBD 


IRTR  Active  EW  Run  3 


IRTR  AEW  R3  Schedule  Risk 
Impact 

=  41  Wks  -  78  Wks 
=  -37  Wks 


Summary  for  CycleTime  (Wks)  Active  EW  Run  3  IRTR 

ActivityName  =  End 


95<N>  Confidence  Intervals 


Anderson-Darling  Normality  Test 

A-Squared 

5.25 

P-Value  < 

0.005 

Mean 

24.792 

StDev 

5.847 

Variance 

34.190 

Skewness 

0.450020 

Kurtosis 

-0.674584 

N 

500 

Minimum 

12.883 

3rd  Quartile 

29.066 

Maximum 

41.412 

95%  Confidence  Interval  for  Mean 

24.279 

25.306 

95%  Confidence  Interval  for  Median 

23.130 

24.438 

95%  Confidence  Interval  for  StDev 

5.508 

6.234 

23j0  235  24j0  245  25j0  255 


IRTR  AEW  R3  Schedule  Risk 
Likelihood 

=  0.0% 


There  is  a  0%  chance  that  the 
schedule  will  exceed  78  weeks. 


357 


Process  Capability  of  CycleTime  (Wks)  Active  EW  Run  3 IRTR 


Process  Data 

LB 

0 

Target 

52 

USL 

78 

Sample  Mean 

24.7924 

Sample  N 

500 

SlDev(Within) 

5.77025 

StDev(Overall) 

5.8472 

-  Within 
>  Overall 


Potential  (Within)  Capability 
Cp  * 

CPL  * 

CPU  3.07 
Cpk  3.07 


Overall  Capability 
Pp  * 

PPL  * 

PPU  3.03 
Ppk  3.03 
Cpm  0.31 


33  44  55  66  77 


Observed  Performance 

Exp.  Within  Performance 

Exp.  Overall  Performance 

%  <  LB 

0.00 

%  <L£  * 

%  <LB 

* 

%  >  USL 

0.00 

%  >  USL  0.00 

%  >  USL 

0.00 

%  Total 

0.00 

%  Total  0.00 

%  Total 

0.00 

IRTR  AEW  R3  Cost  Risk  Impact 
=  Max  -  Mean 
=  $100K  -  $60K  =  $40K 

IRTR  AEW  R3  Cost  Risk  Likelihood 

=  Right  tail  chance  of  exceeding  the 
mean  =  49.40% 


There  is  a  49.40%  chance  that  the 
cost  will  exceed  the  mean  by  $40K. 


b-2  ■1-kJ  ‘i-F’-.j at-: ■  few*?  h.' 


arattw  "krfl  ■ 

<*H'  kPH  ml* 
ijiE  illd 

■s*— -  fiH*  tn 

=  "ua  j  S  \jL  >±a  j  jj.  |.> 


J 

0 


LkirV'hdk  M 

CMgl-pu*  J# 


.  K<- "  — 

rs=si 

LE93r«] 


IRTR  AEW  R3  Increased 
Performance  Risk  Impact 


TBD 


IRTR  AEW  R3  Increased 
Performance  Risk  Likelihood 


TBD 


LRTR  Active  EW  Run  1 
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LRTR  AEW  R1  Schedule  Risk 
Impact 

=  119  Wks-78  Wks 
=  41  Wks 


Summary  for  CycleTime  (Wks)  Active  EW  Run  1  LRTR 

ActivityName  =  End 


Anderson-Darling  Normality  Test 

A-Squared 

0.83 

P-Value 

0.032 

Mean 

76.638 

StDev 

13.373 

Variance 

178.846 

Skewness 

0.373863 

Kurtosis 

0.092144 

N 

500 

95<N>  Confidence  Intervals 


Minimum  44.054 

1st  Quartile  67.062 

Median  75.825 


_  laximum  119.304 

95%  Confide  nee  Interval  hor  MeaiT 

75.463  77.813 

95%  Confidence  Interval  for  Median 
75.043  77.156 

95%  Confidence  Interval  for  StDev 
12.593  14.258 


LRTR  AEW  R1 
Likelihood 

=  45.94% 


Schedule  Risk 


There  is  a  45.94%  chance  that  the 
schedule  will  exceed  78  weeks  by  as 
much  of  41  weeks. 


Process  Capability  of  CycleTime  (Wks)  Active  EW  Run  1  LRTR 


Process  Data 

LB 

0 

USL 

78 

Sample  N 

500 

StDev(Within) 

13.5583 

SlDev(Overall) 

13.3733 

J 


-  Within 
■  Overall 


Potential  (Within)  Capability 
Cp  * 

CPL  * 

CPU  0.03 
Cpk  0.03 


Overall  Capability 
Pp  * 

PPL  * 

PPU  0.03 
Ppk  0.03 
Cpm  0.31 


0  20  40  60 


80  100  120 


Observed  Performance 

Exp.  Within  Performance 

Exp.  Overall  Performance 

%  <  LB 

0.00 

%  <  LB  * 

r-in  * 

%  >  USL 

42.20 

%  >  USL  46.00  < 

%  >  USL  45.94 

2 

%  Total 

42.20 

%  Total  46.00 

... 


LRTR  AEW  R1  Cost  Risk  Impact 
=  Max  Mean 

=  $2,063K  -  $1,41  IK  =  $652K 


LRTR  AEW  R1  Cost  Risk 
Likelihood 

=  Right  tail  chance  of  exceeding  the 
mean  =  46.71% 


There  is  a  46.71%  chance  that  the 
cost  will  exceed  the  mean  by  $652K. 
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LRTR  AEW  Rl  Increased 
Performance  Risk  Impact 


TBD 


LRTR  AEW  Rl  Increased 


TBD 
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Performance  Risk  Likelihood 


LRTR  Active  EW  Run  2 


LRTR  AEW  R2  Schedule  Risk 
Impact 

=  85  Wks  -  78  Wks 
=  7  Wks 


Summary  for  CycleTime  (Wks)  Active  EW  Run  2  LRTR 

ActivityName  =  End 


Ff 


Anderson-DaHing  Normality  Test 

A-Squared 

0.56 

P-Value 

0.146 

Mean 

51.493 

StDev 

11.412 

Variance 

130.236 

Skewness 

0.178396 

Kurtosis 

-0.186802 

N 

500 

95<N>  Confidence  Intervals 


Minimum  22.653 

1st  Quartile  43,147 

Median  50.928 

Ird  riTm--1"*51-  roj3g_ 

_  Maximum _ 84.568 

95%  Confidence  Interval  for  Mean 
50.490  52.496 

95%  Confidence  Interval  for  Median 
49.756  52.283 

95%  Confidence  Interval  For  StDev 
10.746  12.167 


LRTR  AEW  R2  Schedule  Risk 
Likelihood 

=  1.01% 


There  is  a  1.01%  chance  that  the 
schedule  will  exceed  78  weeks  by  as 
much  of  7  weeks. 


Process  Capability  of  CycleTime  (Wks)  Active  EW  Run  2  LRTR 


Process  Data 

LB 

0 

USL 

78 

Sample  N 

SlDev(Within) 

StDev(Overalf) 

500 

11.3379 

11.4121 

-  Within 
>  Overall 


Potential  (Within)  Capability 
Cp  * 

CPL  * 

CPU  0.78 
Cpk  0.78 


Overall  Capability 
Pp  * 

PPL  * 

PPU  0.77 
Ppk  0.77 
Cpm  0.76 


0.0  12.5  25.0  37.5  50.0  62.5  75.0 


Observed  Performance 

Exp.  Within  Performance 

Exp.  Overall  Performance 

%  <  LB  0.00 

%  <IB  * 

_ * 

%  >  USL  1.20 

%  >  USL  0.97  i 

^  %  >  USL  1.01 

%  Total  1.20 

%  Total  0.97 

LRTR  AEW  R2  Cost  Risk  Impact 
=  Max  -  Mean 

=  $  1 ,698K  -  $  1 ,045K  =  $653K 


LRTR  AEW  R2  Cost  Risk 
Likelihood 

=  Right  tail  chance  of  exceeding  the 
mean  =  46.61% 


There  is  a  46.61%  chance  that  the 
cost  will  exceed  the  mean  by  $653K. 
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Laser  Designator  Payload 


Baseline  (BL) 


R1  Simple 

R2  Complex 

R3  Mature 

Schedule  Risk  Impact 

48  Wks 

48Wks 

0  Wks  (-13  Wks) 

Schedule  Risk  Likelihood 

80.80% 

77.55% 

0.000009% 

Cost  Risk  Impact 

$889K 

$891K 

$538K 

Cost  Risk  Likelihood 

47.58% 

47.34% 

45.44% 

Performance  Risk  Impact 

N/A 

N/A 

N/A 

Performance  Risk  Likelihood 

N/A 

N/A 

N/A 

Intermediate  Risk  Timeline  Reduction  (IRTR) 

R1  Simple 

R2  Complex 

R3  Mature 

Schedule  Risk  Impact 

7  Wks 

7  Wks 

0  Wks  (-3  7 Wks) 

Schedule  Risk  Likelihood 

1.22% 

1.22% 

0% 

Cost  Risk  Impact 

$476K 

$72K 

$42K 

Cost  Risk  Likelihood 

44.54% 

49.07% 

49.44% 

Performance  Risk  Impact 

TBD 

TBD 

TBD 

Performance  Risk  Likelihood 

TBD 

TBD 

TBD 

Low  Risk  Timeline  Reduction  f 

LRTR) 

R1  Simple 

R2  Complex 

R3  Mature 

Schedule  Risk  Impact 

7  Wks 

7  Wks 

0  Wks  (-24Wks) 

Schedule  Risk  Likelihood 

0.84% 

0.99% 

0% 

Cost  Risk  Impact 

$653K 

$652K 

$281K 

Cost  Risk  Likelihood 

46.57% 

46.60% 

45.51% 

Performance  Risk  Impact 

TBD 

TBD 

TBD 

Performance  Risk  Likelihood 

TBD 

TBD 

TBD 
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Passive  Electronic  Warfare  Payload 


Baseline  (BL) 


R1  Simple 

R2  Complex 

R3  Mature 

Schedule  Risk  Impact 

163  Wks 

48  Wks 

0  Wks  (-24  Wks) 

Schedule  Risk  Likelihood 

100% 

77.27% 

0% 

Cost  Risk  Impact 

$894K 

$893K 

$538K 

Cost  Risk  Likelihood 

47.74% 

47.72% 

45.44% 

Performance  Risk  Impact 

N/A 

N/A 

N/A 

Performance  Risk  Likelihood 

N/A 

N/A 

N/A 

Intermediate  Risk  Timeline  Reduction  (IRTR) 

R1  Simple 

R2  Complex 

R3  Mature 

Schedule  Risk  Impact 

48  Wks 

7  Wks 

-51  Wks 

Schedule  Risk  Likelihood 

87.16% 

1.26% 

0% 

Cost  Risk  Impact 

$459K 

$455K 

$42k 

Cost  Risk  Likelihood 

45.10% 

45.18% 

49.44% 

Performance  Risk  Impact 

TBD 

TBD 

TBD 

Performance  Risk  Likelihood 

TBD 

TBD 

TBD 

Low  Risk  Timeline  Reduction  (] 

LRTR) 

R1  Simple 

R2  Complex 

R3  Mature 

Schedule  Risk  Impact 

41  Wks 

7  Wks 

0  Wks  (-24  Wks) 

Schedule  Risk  Likelihood 

45.94% 

1.01% 

0% 

Cost  Risk  Impact 

$655K 

$654K 

$281K 

Cost  Risk  Likelihood 

46.69% 

46.59% 

45.51% 

Performance  Risk  Impact 

TBD 

TBD 

TBD 

Performance  Risk  Likelihood 

TBD 

TBD 

TBD 
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Active  Electronic  Warfare  Payload  (Also  Data  Com  and  RADAR) 

Baseline  (BL) _ 


R1  Simple 

R2  Complex 

R3  Mature 

Schedule  Risk  Impact 

163  Wks 

85  Wks 

55  Wks 

Schedule  Risk  Likelihood 

100% 

99.99% 

99.47% 

Cost  Risk  Impact 

$894K 

$898K 

$539K 

Cost  Risk  Likelihood 

47.74% 

47.51% 

45.47% 

Performance  Risk  Impact 

N/A 

N/A 

N/A 

Performance  Risk  Likelihood 

N/A 

N/A 

N/A 

Intermediate  Risk  Timeline  Reduction  (IRTR) 

R1  Simple 

R2  Complex 

R3  Mature 

Schedule  Risk  Impact 

46  Wks 

7  Wks 

0  Wks  (-37  Wks) 

Schedule  Risk  Likelihood 

84.44% 

1.11% 

0% 

Cost  Risk  Impact 

$459K 

$482K 

$40K 

Cost  Risk  Likelihood 

45.10% 

44.36% 

49.40% 

Performance  Risk  Impact 

TBD 

TBD 

TBD 

Performance  Risk  Likelihood 

TBD 

TBD 

TBD 

Low  Risk  Timeline  Reduction  ( 

LRTR) 

R1  Simple 

R2  Complex 

R3  Mature 

Schedule  Risk  Impact 

41  Wks 

7  Wks 

0  Wks  (-24  Wks) 

Schedule  Risk  Likelihood 

45.94% 

1.01% 

0% 

Cost  Risk  Impact 

$652K 

$653K 

$280K 

Cost  Risk  Likelihood 

46.71% 

46.61% 

45.50% 

Performance  Risk  Impact 

TBD 

TBD 

TBD 

Performance  Risk  Likelihood 

TBD 

TBD 

TBD 
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Performance  Risk  Matrices 


(Refer  to  Tables;  Table  5:  Risk  Likelihood  Definitions  and  Table  6:  Risk 

Impact  Definitions  for  Performance  and  Schedule  for  Impact  Risk  and  Risk  Probability 
ratings  scale.) 

Generic  Matrices  IRTR  &  LRTR  Strategies 


GENERIC 

IRTR  Strategy 

Change 

Impact  RiskCf 

Risk  Prob  Pf 

CDL 

No  change 

IFC 

Fast-track  IFC  with  limited  operation  envelope. 

2 

2 

Battery 

Interim  approval.  Battery  could  be  used  in  dangerous 

manner. 

2 

2 

IA 

Interim  approval  (IATO).  Risk  of  compromise  by 
unauthorized  user. 

2 

2 

Spectrum 

Interim  approval  -  Not  to  interfere  basis  assignments 

3 

2 

T&E 

OT  in  fielding.  No  time  to  fix  problems  before  fielding. 

4 

3 

JTIC 

Obtain  a  limited  JITC  in  T&E,  with  full  cert  during 
preliminary  fielding. 

3 

2 

SAASM 

No  change 

Overall  Risk  Ratings: 

3 

3 

Mean  (excluding  zeros) 

r  2.666565657 

r 2.155566667 

Max 

r 

[  4 

r 

3 

LRTR  Strategy 

Change 

Impact  Risk  Cf 

Risk  Prob  Pf 

CDL 

Use  CDL  or  air  platform  data  link.  Limits  payloads  and 
competition. 

1 

1 

IFC 

Fast-track  IFC  with  limited  operation  envelope. 

2 

2 

Battery 

Use  previously  certified  battery.  Limits  payloads  and 
competition. 

1 

1 

IA 

No  Change 

Spectrum 

Use  previously  certified  transmitters.  Limits  payloads 
and  competition. 

1 

1 

T&E 

Joint  DT  and  OT.  No  time  to  fix  problems  before  OT,  but 
can  fix  before  fielding. 

2 

2 

JTIC 

No  Change 

SAASM 

Use  previously  certified  GPS  receivers.  Limits  payloads 
and  competition. 

1 

1 

Overall  Risk  Ratings: 

2 

2 

Mean  (excluding  zeros) 

1.333333333 

r 1.333333333 

Max 

r 

2 

r 

2 
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Laser  Designator  Runs  1,  2,  &  3  Matrices  IRTR  &  LRTR  Strategies 


LASER  DESIGNATOR  RUN  1 

IRTR  Strategy 

Change 

Impact  Risk  Cf 

Risk  Prob  Pf 

IF  C 

Fast-track  IFC  with  limited  operation  envelope. 

2 

2 

Battery 

Interim  approval.  Battery  could  be  used  in  dangerous 

manner. 

2 

2 

IA 

Interim  approval  (IATO).  Risk  of  compromise  by 
unauthorized  user. 

2 

2 

T&E 

OT  in  fielding.  No  time  to  fix  problems  before  fielding. 

4 

3 

JTIC 

Obtain  a  limited  JITC  in  T&E,  with  full  cert  during 
preliminary  fielding. 

3 

2 

Overall  Risk  Ratings: 

3 

3 

Mean  (excluding  zeros) 

2.6 

2.2 

Max 

4 

3 

LRTR  Strategy 

Change 

Impact  Risk  Cf 

Risk  Prob  Pf 

IFC 

Fast-track  IFC  with  limited  operation  envelope. 

2 

2 

Battery 

Use  previously  certified  battery.  Limits  payloads  and 
competition. 

1 

1 

IA 

No  Change 

T&E 

Joint  DT  and  OT.  No  time  to  fix  problems  before  OT,  but 
can  fix  before  fielding. 

2 

2 

JTIC 

No  Change 

Overall  Risk  Ratings: 

2 

2 

Mean  (excluding  zeros) 

1.666666667 

1.666666667 

Max 

2 

2 
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LASER  DESIGNATOR  RUN  2 

IRTR  Strategy 

Change 

Impact  Risk  Cf 

Risk  Prob  Pf 

IFC 

Fast-track  IFC  with  limited  operation  envelope. 

2 

2 

1A 

Interim  approval  (IATO)  Risk  of  compromise  by 

unauthorized  user. 

2 

2 

T&E 

OT  in  fielding.  No  time  to  fix  problems  before 
fielding. 

4 

3 

Overall  Risk  Ratings: 

3 

3 

Ataxn  (excluding  zeros) 

2.666666667 

2.33333333 

Max 

4 

3 

LRTR  Strategy 

Change 

Impact  Risk  Cf 

Risk  Prob  Pf 

IFC 

Fast-track  IFC  with  limited  operation  envelope. 

2 

2 

IA 

No  Change 

T£tE 

Joint  DT  and  OT.  No  time  to  fix  problems  before 

OT,  but  can  fix  before  fielding. 

2 

2 

Overall  Risk  Ratings: 

2 

2 

Mean  (excluding  zeros) 

2 

2 

Max 

2 

2 

LASER  DESIGNATOR  RUN  3 

IRTR  Strategy 

Change 

Impact  Risk  Cf 

Risk  Prob  Pf 

IFC 

Fast-track  IFC  with  limited  operation  envelope. 
Only  HPOL  and  Risks  needed. 

2 

2 

IA 

Interim  approval  (IATO).  Risk  of  compromise  by 

unauthorized  user. 

2 

2 

T&E 

OT  in  fielding.  No  time  to  fix  problems  before 
fielding. 

4 

3 

Overall  Risk  Ratings: 

3 

3 

Mean  zeros) 

2.666666667 

2.33333333 

Max 

4 

3 

LRTR  Strategy 

Change 

Impact  Risk  Cf 

Risk  Prob  Pf 

IFC 

Fast-track  IFC  with  limited  operation  envelope. 
Only  HPOL  and  Risks  needed. 

2 

2 

IA 

No  Change 

T£tE 

Joint  DT  and  OT.  No  time  to  fix  problems  before 

OT,  but  can  fix  before  fielding. 

2 

2 

Overall  Risk  Ratings: 

2 

2 

JVtecm  {excluding  zeros) 

2 

2 

Max 

2 

2 
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Passive  EW  Runs  1,  2,  &  3  Matrices  IRTR  &  LRTR  Strategies 


PASSIVE  EW  RUN  1 

IRTR  Strategy 

Change 

Impact  Risk  Cf 

Risk  Prob  Pf 

CDL 

No  change 

IFC 

Fast-track  IFC  with  limited  operation  envelope. 

2 

2 

Battery 

Interim  approval.  Battery  could  be  used  in  dangerous 

manner. 

2 

2 

IA 

Interim  approval  (IATO).  Risk  of  compromise  by 

unauthorized  user. 

2 

2 

Spectrum 

Interim  approval  -  Not  to  interfere  basis  assignments 

3 

2 

I&E 

OT  in  fielding.  No  time  to  fix  problems  before  fielding. 

4 

3 

JT1C 

Obtain  a  limited  J1TC  in  T&E,  with  full  cert  during 
p  rel  i  m  i  n  a  ry  f  iell  d  i  ng. 

3 

2 

SAASM 

No  change 

Overall  Risk  Ratings: 

3 

3 

Mean  (excluding  zeros) 

2.666666667 

2.16666667 

Max 

4 

3 

LRTR  Strategy 

Change 

Impact  Risk  Cf 

Risk  Prob  Pf 

CDL 

Use  CDL  or  air  platform  data  link.  Limits  payloads  and 
competition. 

1 

1 

IFC 

Fast-track  IFC  with  limited  operation  envelope. 

2 

2 

Battery 

Use  previously  certified  battery.,  Limits  payloads  and 
competition. 

1 

1 

!A 

No  Change 

Spectrum 

Use  previously  certified  transmitters.  Limits  payloads 
and  competition. 

i 

1 

T&E 

Joint  DT  and  OT.  No  time  to  fix  problems  before  OT,  but 
can  fix  before  fielding. 

2 

2 

JTIC 

No  Change 

SAASM 

Use  previously  certified  GPS  receivers.  Limits  payloads 
and  competition. 

1 

1 

Overall  Risk  Ratings: 

2 

2 

Mean  (excluding  zeros) 

1 .333333333 

1.33333333 

Max 

2 

2 
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PASSIVE  EW  RUN  2 

IRTR  Strategy 

Change 

Impact  Risk  Cf 

Risk  Prob  Pf 

1FC 

Fast-track  IFC  with  limited  operation  envelope. 

2 

2 

IA 

Interim  approval  (IAIO).  Risk  of  compromise  by 

unauthorized  user. 

2 

2 

T&E 

OT  in  fielding.  No  time  to  fix  problems  before 
fielding. 

4 

S 

Overall  Risk  Ratings: 

3 

3 

Mean  (excluding  zeros} 

2.666666667 

2.33333333 

Max 

4 

3 

LRTR  Strategy 

Change 

Impact  Risk  Cf 

Risk  Prob  Pf 

IFC 

Fast-track  I  FC  with  limited  operation  envelope. 

2 

2 

IA 

No  Change 

T£tE 

Joint  □  T  and  0 T.  No  time  to  fix:  probl  ems  before 

01,  but  can  fix  before  fi  el  ding. 

2 

2 

Overall  Risk  Ratings: 

2 

2 

Mean  (excluding  zeros) 

2 

2 

Max 

2 

2 

PASSIVE  EW  RUN  3 

IRTR  Strategy 

Change 

Impact  Risk  Cf 

Risk  Prob  Pf 

IFC 

Fast-track  IFC  with  limited  operation  envelope. 
HPOL  and  Risks  only. 

2 

2 

IA 

Interim  approval  (IAIO).  Risk  of  compromise  by 

unauthorized  user. 

2 

2 

TfrE 

OT  in  fielding.  No  time  to  fix  problems  before 
fielding. 

4 

3 

Overall  Risk  Ratings: 

3 

3 

Mean  (excluding  zeros} 

2.666666667 

2.33333333 

Max 

4 

3 

LRTR  Strategy 

Change 

Impact  Risk  Cf 

Risk  Prob  Pf 

IFC 

Fast-track  IFC  with  limited  operation  envelope. 
HPOL  and  Risks  only. 

2 

2 

IA 

No  Change 

t&  e 

Joint  DT  and  OT.  No  time  to  fix  probl  ems  before 

OT,  but  can  fix  before  fielding.  Run  3  has  NO  DT  so 
no  OT.  No  time  to  fix  problems  before  fielding. 

2 

2 

Overall  Risk  Ratings: 

2 

2 

Mean  (excluding  zeros) 

2 

2 

Max 

2 

2 
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Active  EW  Runs  1,  2,  &  3  Matrices  IRTR  &  LRTR  Strategies 


Active  EW  RUN  1 

IRTR  Strategy 

Change 

Impact  Risk  Cf 

Risk  Prob  Pf 

CDL 

No  change 

IF  C 

Fast-track  IFCwith  limited  operation  envelope. 

2 

2 

Battery 

Interim  approval.  Battery  could  be  used  in  dangerous 

manner. 

2 

2 

IA 

Interim  approval  (IATO).  Risk  of  compromise  by 
unauthorized  user. 

2 

2 

Spectrum 

Interim  approval  -  Not  to  interfere  basis  assignments 

3 

2 

T&E 

OT  in  fielding.  No  time  to  fix  problems  before  fielding. 

4 

3 

JTIC 

Obtain  a  limited  JITC  in  T&E,  with  full  cert  during 
preliminary  fielding. 

3 

2 

SAASM 

No  change 

Overall  Risk  Ratings: 

3 

3 

Mean  (excluding  zeros) 

2.656665667 

2 .1 66656667 

Max 

4 

3 

LRTR  Strategy 

Change 

Impact  Risk  Cf 

Risk  Prob  Pf 

CDL 

Use  CDL  or  air  platform  data  link.  Limits  payloads  and 
competition. 

1 

i 

IFC 

Fast-track  IFCwith  limited  operation  envelope. 

2 

2 

Battery 

Use  previously  certified  battery.  Limits  payloads  and 
competition. 

1 

1 

IA 

No  Change 

Spectrum 

Use  previously  certified  transmitters.  Limits  payloads 
and  competition. 

1 

1 

T&E 

Joint  DT  and  OT.  No  time  to  fix  problems  before  OT,  but 
can  fix  before  fielding. 

2 

2 

JTIC 

No  Change 

SAASM 

Use  previously  certified  GPS  receivers.  Limits  payloads 
and  competition. 

1 

1 

Overall  Risk  Ratings: 

2 

2 

Mean  (excluding  zeros) 

1.333333333 

1.333333333 

Max 

2 

2 
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Active  EW  RUN  2 

1 RTR  Strategy 

Changa 

Impact  RiskCf 

RiskProb  Pf 

IFC 

Fast-track  IFC  with  limit  Ed  operation  a  nvs  lo  p  a . 

2 

2 

IA 

Intarim  approval  IIATO).  Risk  of  compromise  by 

unauthorized  user. 

2 

2 

Spectrum 

Intarim  a  pprova  1  -  Not  to  intErfsrE  basis  assignments 

3 

2 

T&E 

CT  i  n  f i  e  Id  i  ng.  No  ti  m  e  to  fix  p  ro  b  1  e  ma  b  afo  ra  f i  e  Id  i  ng. 

4 

3 

Overall  Risk  Ratings: 

3 

3 

Mean  (exdu ding  zeros} 

2.75 

2.25 

Mux 

4 

3 

LRTR  Strategy 

ChangE 

Impact:  RiskCf 

RiskProb  Pf 

IFC 

Fast-track  IFC  with  limit  Ed  operation  envelope. 

2 

2 

IA 

No  ChangE 

Spectrum 

Ua  a  p  ra  vio  us  ly  cart  if  i  Ed  t  ra  na  m  itt  a  rs.  Li  m  ita  p  ay  lo  ada 
and  competition. 

1 

1 

TS.E 

Jo int:  DT  a nd  CT.  No  t  i  m  a  to  fix  p  ruble ma  b afo ra  CT,  but 
can  fix  b  afo  ra  f  i  a  Id  i  ng. 

2 

2 

Overall  Risk  Ratings: 

2 

2 

Meoxi  (excluding  zeros) 

i.eeeeeee€7 

1.665565  7 

Mux 

2 

2 

Active  EW  RUN  2 

1  RTR  Strategy 

ChangE 

Impact  RiskCf 

RiskProb  Pf 

IFC 

Fast-track  IFC  with  limit  ad  operation  anvalopa.  HPCL 
and  Risks  only. 

2 

2 

IA 

Intarim  approval  IIATO).  Risk  of  compromise  by 

unauthorized  uaar. 

2 

2 

Spactrum 

1  nt  a  ri  m  a  p  p  rova  1  -  Not:  to  i  nt  a  rfE  ra  b  aa  ia  ass ign  m  a  nts 

3 

2 

T&E 

OT  i  n  f  i  a  Id  i  ng.  No  ti  m  a  to  fix  p  ro  b  1  a  ma  b  afo  ra  f  i  a  Id  i  ng. 

4 

3 

Overall  Risk  Ratings: 

3 

3 

Mean  (excluding  zeros) 

2.75 

2.25 

Mux 

4 

3 

LRTR  Strategy 

Change 

Impact:  RiskCf 

RiskProb  Pf 

IFC 

Fast-track  IFC  with  limit  ad  operation  anvalopa.  HPCL 
and  Risks  only. 

2 

2 

IA 

No  Change 

Spactrum 

Ua  a  p  ravio  us  ly  c a  rtif i ad  t  ra nsm  itt  a  ra.  Li  m  its  p  aylo  ada 
and  competition. 

1 

1 

TElE 

Joint  DT  and  CT.  No  time  to  fix  problems  before  CT,  but 
can  fi.^s  b  afo  ra  f  i  a  Id  i  ng.  Ru  n  ,3  has  NO  DT  so  no  OT.  No 
time  to  fi^  p  ro  b  1  a  ma  b  afo  ra  f  i  a  Id  i  ng. 

2 

2 

Overall  Risk  Ratings: 

2 

2 

Meun  (excluding  zeros) 

1.666666667 

1.666666 7 

Mux 

2 

2 

APPENDIX  H.  RAPID  PAYLOAD  INTEGRATION  CHECKLIST 


Section  1 :  The  Rapid  Payload  Integration  Checklist  is  a  product  of  the  RAIN  Team 
Research  and  is  a  deliverable  item  to  PMA-265  for  future  integration  projects. 


Section  2:  Component  Analyses  and  Attribute  Investigation:  Certification  Justification  of 

Payload  Integration  Checklist 
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PMA-263  Payload  Integration  Checklist 


Description:  The  Integration  Checklist  provides  a  detailed  list  of  all  system -level  SE  work  that  needs 
to  be  addressed  to  properly  integrate  a  new  capability.  Each  item  in  the  list  addresses  the  applicability, 
responsible  IMAVAIR  competency,  guiding  instructions,  approval  authority,  and  documentation.  The  goal 
of  this  list  is  to  capture  the  systems-level  requirements  for  certification  of  a  new/modified  payload.  This 
list  provides  a  technology  developer  the  information  needed  to  scope  and  execute  comprehensive 
integration  of  their  payload  to  support  timely  fielding. 

Safety  Components 

Airworthiness  -  Interim  Flight  Clearance  (IFC) 

[]  Applicable  []  Not  Applicable 

1.  Applicability:  All  air  vehicles  and  aircraft  systems  owned  or  leased  by  any  DON  entity  or  component 
An  IFC  is  required  for  standard  and  new/modified  aircraft  system  configurations,  including 
hardware,  firmware,  and  software;  flight  envelopes;  and  operation.  This  includes  stores  and  store 
suspension  equipment,  Aviation  Life  Support  Systems,  and  airborne  /surface-based  components. 

2 .  N  AVAI R  Com petency :  AIR  4. OP  -  Ai r worthiness  Office 

3.  Instructions 

a.  Guiding  :  Title  49  USC,  Sec  40103  -  Sovereignty  and  Use  of  Airspace 

b.  Sub:  NAVA1R INST  13034. ID 

4.  Approval  Authority 

a.  Full  certification  -  NAVAIR  4. OP 

b.  Waiver  —  N/A 

c.  Interim  -  N/A 

5.  Required  documentation 


V 

Delivered  on 
Date  (dd/mo/yT) 

Document 

/  / 

Interim  Flight  Clearance  (IFC)  Data  Requirements  Spreadsheet 

!  / 

RCC  323-99  Range  Safety  Criteria  for  UAV's  Risk  Assessment  Questionnaire 

/  1 

Higher  Probability  of  Loss  (HPOL) 

i  / 

Navy  Type  Command  (TYCOM)  Concurrence 

1  1 

Laser  Safety  Review  Board  (LSRBj  Approval  [Laser] 

I  / 

Naval  Ordnance  Safety  &  Security  Activity  (NOSSA)  Approval  [Battery] 

i  / 

Weapons  Systems  Explosive  Safety  Review  Board  (WSESRB)  Approval  [Weapons] 

I  / 

System  Safety  Risk  Assessment  (SSRA) 
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Battery 

[]  Applicable  []  Not  Applicable 

1.  Applicability:  All  lithium  (Li)  battery-powered  devices  intended  for  use  or  transportation  on  Navy 
facilities,  submarines,  ships,  vessels,  and  aircraft.  This  includes  all  primary  (non-rechargeable)  and 
secondary  (rechargeable),  active,  thermal  and  reserve  Li  batteries,  including  Li-ion  batteries  and  all 
equipment  power3ed  by  Li  electrochemical  power  source(s)  through  all  phases  of  the  life  of  such 
systems. 

2.  NAVAIR  Competency:  AIR  4.4  -  Propulsion  &  Power 

3.  Instructions 

a.  Guiding : 

1)  NAVSEA  INST  9310.  IB 

b.  Sub: 

1)  NAVSEA  S9310-AQ-SAF-010 

4 .  A  pp  ro  va  I  Auth  or  i  ty 

a.  Full  certification  - 
1)  NOSSA 

b.  Waiver  -  N/A 

NOTE:  NOSSA  will  not  issue  a  waiver  for  9310  safety  requirements,  but  may  issue  an  interim 
approval  to  operate  the  subject  battery  for  a  limited  amount  of  time. 

c.  Interim  -  N/A 

NOTE:  NOSSA  and  IMAVAIR  (4. 4. 5, 2):  Although  waivers  are  not  granted,  an  interim  approval  may 
be  granted,  but  the  NOSSA  and  NAVAIR  4.4.5. 2  must  concur  with  the  interim  approval. 

5.  Required  documentation 


V 

Delivered  on 
Date  ^dd/mo/yO 

Document 

/ 

/ 

Battery  Exemption 

/ 

/ 

Battery  Cell  Drawing 

/ 

/ 

Battery  Schematic  Drawing 

I 

/ 

CONOPS 

/ 

/ 

Payload  Technical  Manual 

/ 

/ 

Battery  Safety  Data  Package 

/ 

/ 

Request  Letter  Signed  by  PM  A 

Note:  Some  Li  batteries  do  not  require  safety  (see  NAVSEA  S9310-AQ-SAF-010  for  details),  but  a  safety 
assessment  must  be  completed.  The  NOSSA  Technical  Agent  will  determine  the  level  of  9310  safety 
testing  required  based  on  the  documentation  provided  with  the  approval  request. 
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Laser 

[]  Applica  ble  [)  Not  A  ppl  icable 

1,  Applicability:  Class  38  and  4  lasers  used  in  optical  fiber  communications  systems,  ell  DON  lasers  used 
in  combat,  combat  training,  or  classified  in  the  interest  of  national  security  and  ail  laser  system s 
capable  of  exceeding  Class  3  R  levels,  except  those  planned  solely  for  industrial,  construction, 
medical,  or  indoor  experimental  lab  use, 

2 ,  N  Al/Al  R  Cam  patency :  A I  ft  4 .  6  -  Hu  man  System  s 
3=  Instructions 

a,  Guiding; 

1)  Title  21,  Code  of  federal  Regulations  (CFR),  Parts  1040P 1040.10,  arid  1040.11 

2)  DoD  Instruction  6055,15 

b.  Sub: 

1)  DoD  Instruction  6055.15 
2 1  OPNAl/INST  5100,278 

3]  Exemption  No.  76EL-01BGD,  Letter  of  Exemption  from  die  Food  and  Drug 

Administration  (FDA)  for  DoD  Exemption  from  Provisions  of  21  CFFt  1040>  July  29, 19261 

4.  Approval  Author \ty 

a,  Full  certification  -  LASER  Safety  Review  Board  (LSRBJ 

b.  Waiver  -N/A 
cr  Interim -N/A 

5 ,  Req  ui  red  docu  mentation 


V 

DtSvtrtd  tti 
Cute  idd/moATh 

Document 

/  / 

LASER  Characterization  Test  Report  (ANSI  2136.4,.  Recommended  Practice  for  Laser 
Safety  Measurements  for  Hazard  Evaluation) 

/  / 

Design  Checklist  5100.278 

/  / 

Military  Exemption  Letter 

Weapons  System  Explosives  Safety  Review  Hoard  (WSESRR)  (Weapons 

Certification) 

[]  Applicable  [)  Not  A  ppl  icable 

1.  Applicability:  Any  system  that  requires  the  use  of  ANY  explosive(s)  to  complete  its  mission,  Such  as 
all  ordnance  item y,  explosives  systems;  weapon  systems;  related  fire  control  systems;  conventional 
components  of  nuclear  weapons  containing  energetic  materials,  weapon  deuces,  ignition  devices 
(squibs),  bolts,  release  mechanisms,  or  systems,  This  includes  demonstration  Firings,  evaluations,  or 
foreign  comparative  testing,  regardless  of  country  of  origin,  military  service  prepotency,  design 
source,  or  manufacturing  source  when  their  use  ar  stowage  will  be  aboard  a  Navy-owned  or 
contracted  vessel  or  aircraft, 

2 .  N  A  VAI R  Com  petenc y :  A I R  4 . 1 . 6  ( Nations  I  NAV  Al  R  competency  For  system  sa  fety ) 

3.  Instructions 
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a.  Guiding  :  NAVSEAINST  E020.6E  (200S) 

b.  Sub;  Paragraph  6.b.2. 

4.  Approval  Authority 

a.  Full  certification  -  Recommendations  to  PM,  CNQ,  and  MDA  by  the  WSESftR 

b.  Waiver:  Yes,  High  Risk  is  delegated  to  ASN  (RDA),  Serious  Risk  is  delegated  to  the  PEO,  and 
Moderate  to  Low  Rial  is  delegated  bo  the  Program  Manager  level  with  concurrence  of  residual 
risk  by  the  WSESRB. 

Cr  Interim -N/ A 

5 .  Req  ui  red  doc  u  mentation 


V 

nyfium  k«j  en 
Uatt  1  dd/moA'il 

Document 

/  / 

Review  request  from  PM  to  WSESRB  secretariat  member. 

!  i 

Technical  Data  Packages 

System  Safety 

[J  Applicable  []  Not  Appl  icable 

1 .  Applies  bil  ity :  A  H  system  s  to  identify  a  nd  assess  ESQ  H  ha  za  rd&,  a  s  wel  I  as  m  itlgate  ESQ  H  risks, 

2 .  N  A  VAI R  Com  potency:  A I R  4 , 1. 6  -  Sys tan  Sa  fety 

3.  instructions 

a.  Guiding  : 

1)  5ECNAVIN5T  5Q0G.2D 

2)  MIL-5TD-&S2 

b.  Sub:  NAVAIFINST5100.il 

4.  Approval  Authority 

a .  Full  cer  tif  ication  -  System  5a  fety 

b.  Waiver -N/A 

c.  Interim  -  M/A 

5 .  Req  ui  red  doc  u  mentation 


DrfverwJ  on 

C.-.tf:  1  J>d,,'rYi-i/|1ri  \ 

Document 

f  ( 

ESOH  Hazards  Analysis 

/  ) 

System  Safety  Engineering  Plan  (S5EP) 

i  I 

Operator  and  Maintainor  manuals 

/  / 

Hazardous  Materials  Management  Plan  (HMMP) 

/  / 

Programmatic  Environmental,  Safety,  and  Health  Evaluation  (PESHE) 

/  / 

Failure  Mode  Effects  and  Criticality  Analysis  (FMECA) 

/  / 

Hazards  of  Electromagnetic  Radiation  to  Personnel  (HERP| 

/  / 

Hazards  of  Electromagnetic  Radiation  to  Fuel  (HERE)  calculations 

/  / 

NOS5A  approval  of  lithium  batteries 

/  / 

Material  Safety  Data  Sheet  (M S-DSf  Jem peraty re  Change 
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Range  Safety 


[]  Applicable  []  Not  Applica  ble 

1.  Applicability:  Any  system  that  requires  the  use  of  any  Navy  and  Marine  Corps  air-to-ground  range 
installations  with  the  confines  of  the  United  States,  its  territories,  trusts,  and  possessions, 

2.  NAVAIR  Competency:  AIR  5.2  -  NAVAIR  Range  Department 

3.  Instructions 

a.  Guiding:  NAVAIRINST 3200.3 

b.  Sub:  OPNAV1NST  3550.1A 

4.  Approval  Authority 

a.  Full  certification  -  concurrence  of  the  Range  Safety  Officer 

b.  Waiver  -N/A 

c.  Interim  -  N/A 

5.  Required  documentation -N/A 


V 

Delivered  on 
Date  (dd/mo/vr) 

Document 

/  / 

Signed  Test  Plan 

/  / 

Airworthiness  Certificate 

/  / 

JF-12 

/  t 

LSRB  approval  with  an  assigned  Laser  Safety  Officer  (LSO) 

/  / 

WSESRB  Approval 

/  / 

Range  Scheduling  Information 

Electromagnetic  Environmental  Effects  (E3) 

[]  Applicable  []  Not  Applicable 

1.  Applicability:  All  NAVAIR  platforms,  weapon  systems,  Aircraft  Launch  and  Recovery  Equipment 
(ALRE)  systems,  Air  Traffic  Control  (ATC)  and  landing  systems,  networks,  facilities,  sensors,  electric  or 
electronic  equipment,  ordnance,  and  support  equipment  developed,  procured,  acquired,  leased, 
operated,  modified  or  maintained  by  NAVAIR,  including  commercial  off  the  shelf  (COTS)  items  and 
non- developments  I  items  (NDI). 

2.  NAVAIR  Competency:  AIR  4.1.13  -  Electromagnetic  Environmental  Effects  (E3)  Division 

3.  Instructions 

a.  Guiding  : 

1)  SECNAVINST  5000.2D 

2)  GPNAVINST  2400. 20F 

3)  NAVA  I RINST  2400.1 

b.  Sub: 

1)  MIL-STD-464C 

2)  M1L-STD-461F 

3)  NAVAIR  16-1-529 

4.  Approval  Authority 

a.  Full  certification  - 

1)  AIR-  4.1.13  (E3  Division)  -  Aircraft 
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2)  NOSSA  -  HERO,  HERF  Ship  &  Shore,  HERP  Ship  &  Shore 

b.  Waiver 

1)  CNO  (N6) 

2)  WSESRB  &  NOSSA  -  Hazards  of  Electromagnetic  Radiation  to  Ordnance  (HERO) 

c.  Interim  -  N/A 

5.  Required  documentation 


V 

Delivered  on 
Date  (dd/mo/yr) 

Document 

/  / 

E3  Integration  and  Analysis  Report  (E3IAR)  as  a  minimum. 

/  / 

E3  Verification  Report  -  (Up  to  twelve  different  ones  may  be  required  as  detailed 
the  E3IAR) 

/  / 

RADHAZ  Analysis  for  HERO/F/P  as  required  in  the  E3IAR. 
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Security  Components 
Information  Assurance  (IA) 

[]  Applicable  []  Not  Applicable 

1.  Applicability:  DON-owned  or-controlled  Information  Systems  that  receive,  process,  store,  display,  or 
transmit  DOD  information,  regardless  of  classification  or  sensitivity. 

2.  NAVAIR  Competency:  AIR  7.2.6  -  Information  Assurance 

3.  Instructions 

a.  Guiding : 

1)  DODD8500.01E 

2)  DODI  8500.2 

b.  Sub: 

1)  DODI  8510.01 

4.  Approval  Authority 

a.  Full  certification  -Operational  Designated  Accrediting  Authority  (ODAA),  NAVAIR  Chief 
Information  Officer  (CIO) 

b.  Waiver -N/A 

c.  Interim  -  Yes,  IA7T  (Interim  Authority  to  Test),  IATO  (Interim  Authority  to  Operate)  by  DAA 
(Designated  Accrediting  Authority)  for  a  limited  time 

5.  Required  documentation 


V 

Delivered  on 
Date  (dd/mo/yr) 

Document 

/  / 

Security  Classification  Guide  (SCG) 

/  / 

Configuration  and  Architecture  Description 

/  / 

Network  Architecture  Diagram 

/  / 

Ports  and  Protocols  List 

/  / 

Hardware/Software  (HW/SW)  list 

/  / 

Vulnerabilities  Scan 

Anti-Tamper 

[]  Applicable  []  Not  Applicable 

1.  Applicability:  DON-owned  or  -operated  systems  that  require  the  protection  of  critical  program 
information  (CPI). 

2.  NAVAIR  Competency:  AIR  4.1.14  -  Anti  Tamper  Executive  Agent  (ATEA) 

3.  Instructions 

a.  Guiding : 

1)  DODI  5000.2 

2)  DODI  5200.39 

b.  Sub: 

1)  AT  Guidelines  Version  2 

4.  Approval  Authority 
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a.  Full  certification  -  ATEA,  Al  R-  4, 1.14 

b.  Waiver  -N/A 

c.  Interim  -  Yes,  Interim  Authority  to  Test  (I ATT)  may  be  issued  by  the  Designated  Accrediting 
Authority  (DAA)  [NAVAIR  CIO),  and  Interim  Authority  to  Operate  (IATO)  may  be  issued  for  use  of 
the  system  for  a  limited  time  prior  to  obtain  the  certification, 

5.  Required  documentation 


V 

Delivered  on 
□ate  (dd/mo/yr) 

Document 

/  / 

Anti-Tamper  (AT)  Plan 

/  / 

Critical  Program  Information  (CPI)  Assessment 

Selective  Availability  Anti -Spoofing  Module  (SAASM)  Global  Positioning 
System  (GPS) 

[]  Applicable  []  Not  Applicable 

1.  Appl  ica  bi lity :  Any  system  or  a  ir  vehicle  equ  ipped  with  DoD  G  PS  systems, 

2.  NAVAIR  Competency:  AIR  4.5-  Avionics 

3.  Instructions 

a.  Guiding: 

1]  DOD  GPS  Security  Policy  04  April  2006 

2]  2007  CJCS  Master  Positioning,  Navigation,  and  Tim ing  Plan  GCSI  6130.01  D 

3]  GPU -09-105  Security  Approval  Review  Process  Requirement  Doc  for  GPS  SAASM  HAE 

b.  Sub: 

1)  2007  CJCS  Master  Positioning,  Navigation,  and  Timing  Plan  GCSI  6130.01  D  13  April  2007. 

2)  GPU  -09 - 105  Sec  u  r  ity  Ap  p  ro  va  I  Rev  ie  w  Process  Req  u  i  rem  ent  Doc  for  G  PS  S  A  AS  M  H  A  E 

3)  ICD-  GPS-227  GPS  HAE  Design  Requirements  with  SAASM 

4.  Approval  Authority 

a.  Full  certification  -  G  PSD 

b.  Waiver- Assistant  Secretary  of  Defense 

c.  Interim  -  N/A 

5.  Required  documentation 


V 

Delivered  on 
Date  (dd/mo/yr) 

Document 

/  / 

Technical  Data 

Page  S  of  15 


JUI 


Payload  Integration  Checklist  2013 


Clinger-Cohen  Act 

[]  Applicable  []  Not  Applicable 

1.  Applicability:  Any  system  or  system  that  requires  the  use  of,  acquires,  or  manages  Information 
Technology  resources. 

2.  NAVAIR  Competency:  AIR  7.2.6  -  Clinger-Cohen  Act  (CCA)  Center  of  Excellence  (COE) 

3.  Instructions 

a.  Guiding  :  DoDI  5000.2 

b.  Sub:  SECNAVINST  5000.2 

4.  Approval  Authority 

a.  Full  certification  -  Cognizant  Chief  Information  Officer  (CIO) 

b.  Waiver  -  N/A 

c.  Interim  -  N/A 

5.  Required  documentation 


V 

Delivered  on 
Date  (dd/mo/yr) 

Document 

/  / 

CCA  Compliance  Table  populated  with  MDA  specified  program  governing 
documentation 

/  / 

Acquisition  Information  Assurance  Strategy. 
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Interoperability 

Joint  Interoperability  (JITC) 


[]  Applicable  []  Not  Applicable 

1.  Applicability:  All  Information  Technology  (IT)  acquired,  procured  (systems  or  services),  or  operated 
by  any  DoD  component  that  exchange  and  use  information  to  enable  units  or  forces  to  operate  in 
joint,  combined,  coalition,  and  interagency  operations. 

2.  Competency:  PM  A  with  the  JITC  Representative 

3.  Instructions 

a.  Guiding  : 

1)  DODD  4630.5 

2)  DODI  4630.8 

3)  DODI  5000.1 

4)  DODI  5000.2 

5)  CJCSI6212.01D 

6)  CJCSI3170.01F 

7)  CJCSM3710.01C 

b.  Sub:  N/A 

4.  Approval  Authority 

a.  Full  certification -Joint  Staff  J-6 

b.  Waiver  -  N/A 

c.  Interim -Yes 

5.  Required  documentation 


V 

Delivered  on 
Date  (dd/mo/yr) 

Document 

/  / 

ICEP/ITP  (Interoperability  Certification  Evaluation  Plan/Interoperability  Test  Plan) 

— 

At  a  minimum  the  DODAF  Views  as  follows: 

/  / 

STV-1 

/  / 

SV-6  or  OV-3 

/  / 

SV-4 

/  / 

SV-1 

/  / 

SV-2 

/  / 

(Additional  Views  please  add) 
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Spectrum 

[]  Applicable  []  Not  Applicable 

1.  Applicability:  All  NAVAIR  platforms,  weapon  systems,  Aircraft  Launch  and  Recovery  Equipment 
(ALRE)  systems,  Air  Traffic  Control  (ATC)  and  landing  systems,  networks,  facilities,  sensors,  electric  or 
electronic  equipment,  ordnance,  and  support  equipment  developed,  procured,  acquired,  leased, 
operated,  modified  or  maintained  by  NAVAIR,  including  commercial  off  the  shelf  (COTS)  items  and 
non-developmental  items  (NDI). 

2.  NAVAIR  Competency:  AIR  4.1.M  -  E3  Engineering  and  Spectrum  Support 

3.  Instructions 

a.  Guiding:  Title  47  US  Code  §305,  §901-904 

b.  Sub: 

1)  47  CFR  30 

2) DoD  4650.01 

3) SECNAVINST  2400.1 

4) OPNAVINST  2400. 20F 

5) NAVAIR  INST  2400.1 

4.  Approval  Authority 

a.  Full  Certification  — 

1)  National  Telecommunications  and  Information  Administration  (NTIA) 

2)  NTIA  Spectrum  Planning  Subcommittee 

b.  Waiver -N/A 

c.  Interim  -  N/A  (exception:  interim  ATO  granted  with  submission  to  SPS  or  local  NTIA  7.11 
Authority  for  limited  duration) 

5.  Required  documentation 


V 

Delivered  on 
Date  (dd/mo/yr) 

Document 

/  / 

JF-12  Note  to  Holder  (NTH) 

/  / 

1494  in  EL-CID  Format 

/  / 

Standard  Frequency  Action  Format  (SFAF) 
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Common  Data  Link  (CDL) 

[]  Applicable  []  Not  Applicable 

1.  Applicability:  All  systems  utilizing  a  radio  frequency  data  or  communications  link. 

2.  N  AVAIR  Com  petency :  AIR  4.  5  -  Avionics 

3.  Instructions 

c.  Guiding ;  H.R.  1815  National  Defense  Authorization  Act  for  FY  2006 

d.  Sub:  ASD  memo  DoD  CDL  Policy,  30  Dec  2005 

4.  Approval  Authority 

e.  Full  certification  -  Milestone  Decision  Authority  (MDA) 

f.  Waiver- DoD  CIO 

g.  Interim  -  N/A 

5.  Required  documentation 


V 

Delivered  on 
□ate  (dd/mo/yi) 

Document 

/  / 

Technical  Data 

Identification  Friend  or  Foe  (AIMS  -  part  of  Air  Platform) 

[]  Applicable  []  Not  Applicable 

1.  Applicability:  All  air  vehicles  or  aircraft  that  need  to  differentiate  or  be  differentiated  for  either  being 
a  friendly  force  or  a  foe/enemy. 

2.  N AVAIR  Competency:  AIR  4.5  -  Avionics 

3.  Instructions 

a.  Guiding: 

1)  DoD  International  AIMS  Program  Management  Plan,  dated  21  October  2010, 

2)  DoD  Internationa i  AIMS  Steering  Committee  Charter,  dated  29  April  1977, 

3 )  USA  F  P  rogra  m  M  a  na  gem  e  nt  Di  recti  ve  ( P  M  D]  8 2 3 3 (6)/P  E63724 F,  da  ted  1 5  J  u  ly  2002 . 

b.  Sub:  none 

4.  Approval  Authority 

a.  Full  certification  -  Air  Traffic  Control  Radar  Beacon  System,  Identification  Friend  or  Foe,  Mark 
Xll/Mark  XIIA,  Systems  (AIMS]  (AIMS  PO,  Warner  Robins  AFB,  GA) 

b.  Waiver -N/A 

c.  Interim -Yes 

5.  Required  documentation 


V 

Delivered  on 
Date  (dd/mo/yr) 

Document 

/  / 

Technical  Data 

Page  12  of  IS 


Payload  Integration  Checklist  2013 


Identification  Friend  or  Foe  (NMSC) 

[]  Applicable  []  Not  Applicable 

1.  Applicability:  All  air  vehicles  or  aircraft  that  need  to  differentiate  or  be  differentiated  for  either  being 
a  friendly  force  or  a  foe/enemy. 

2.  NAVAIR  Competency:  AIR  4.1.M  -  E3  Engineering  and  Spectrum  Support 

3.  Instructions 

c.  Guiding:  OPNAVINST2400.20F 

d.  Sub:  none 

4.  Approval  Authority 

d.  Full  certification  -  Navy-Marine  Corps  Spectrum  Center  (NMSC) 

e.  Waiver -N/A 

f.  Interim -Yes 

5.  Required  documentation 


V 

Delivered  on 
Date  (dd/mo/yr) 

Document 

/  / 

Technical  Data 
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Compatibility  Components 

Environmental 

[]  Applicable  []  Not  Applicable 

1.  Applicability:  All  systems  consisting  of  aviation  materials,  structures,  electronics,  subassemblies  and 
components  that  are  exposed  directly  to  the  environment  in  order  to  fulfill  a  mission. 

2.  NAVAIR  Competency:  AIR  4.3.4  -  Aerospace  Materials  Division 

3.  Instructions 

a.  Guiding : 

1)  Corrosion  Prevention  Control  Plan  (CPCP)  PMA-263 

2)  SECNAVINST  5000.2E 

b.  Sub: 

1)  MIL-STD-810 

4.  Approval  Authority 

a.  Full  certification -AIR -4.3.4.6  (Corrosion  &Wear  Branch) -Materials  Engineering  Division 

b.  Waiver-  AIR-4.3.4  Senior  Materials  Engineer 

c.  Interim  -  AIR-  4.3. 4.6  (Corrosion  &  Wear  Branch)  -  Materials  Engineering  Division  AIR-  4.3.4 

5.  Required  documentation 


V 

Delivered  on 
Date  (dd/mo/yr) 

Document 

/  / 

Laboratory  reports  from  a  certified  test  laboratory  for  applicable  MIL-STD-810 
tests  as  outlined  in  the  CCP  (examples  as  below) 

/  / 

Humidity 

/  / 

Salt  Atmosphere  (acidified  &  non-acidified) 

/  / 

Dust  Test 

/  / 

Rain  Test 

/  / 

High  Temperature  Operational  &  Non-Operational 

/  / 

Internal  Operational  Temperature 

/  / 

Low  Temperature  Operational  8i  Non-Operational 

/  / 

Temperature  Change 

/  / 

Shock  per  MIL-STD  -810G  Methods  for  flight,  launch,  recovery,  & 
transportation,  equipment/payload  per  MIL-S-901D 

/  / 

Vibration  per  MIL-STD-810G  Methods  for  flight,  launch,  recovery  & 
transportation,  equipment/payload  per  MIL-STD-167-1A 
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Test  &  Evaluation 

[]  Applicable  []  Not  Applicable 

1.  Applicability:  All  air  vehicles  and  payloads  that  require  developmental/operational  test  and 
evaluation  to  prove  out  mission  capabilities. 

2.  N A VA I R  Competency:  AIR  5.0 -Test  Directorate 

3.  Instructions 

a.  Guiding : 

1)  DoD  Directive  5000.1,  Defense  Acquisition  Systems  (DAS) 

2)  DoD  Instruction  5000.02,  Operation  of  the  DAS  CJCSI  3170.01, 

3)  Joint  Capabilities  Integration  &  Development  System  (JCIDS) 

b.  Sub: 

1)  SECNAVINST  5000.2, 

2)  Department  of  the  Navy  (DON)  Implementation  &  Operation  of  the  DAS  &  the  JCIDS 

3)  NAVAIRINST  3960.2, 

4)  Acquisition  Test  &  Evaluation 

4.  Approval  Authority 

a.  Full  certification  -  AIR  5.0,  Air  Test  and  Evaluation  Squadron  (VX-XX) 

b.  Waiver  -N/A 

c.  Interim  -  N/A 

5.  Required  documentation 


V 

Delivered  on 
Date  (dd/mo/yr) 

Document 

/  / 

Completed  PMA-263  Test  Project  Worksheet 

/  / 

TEMP  (Test  and  Evaluation  Master  Plan) 

/  / 

Test  Plan 

/  / 

Test  Supportability  Plan 

/  / 

Test  Cards 

/  / 

Test  Reports 
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(United  States  Navy  201 1), (United  States  Navy  2006b) ,  (United  States  Air  Force  2010), 
(United  States  Air  Force  2007) 

Page  6 
None 

Page  7 

(United  States  Department  of  Defense  2003)(United  States  Department  of  Defense 
2007a), (United  States  Department  of  Defense  2008a),  (United  States  Department  of 
Defense  2010a) 

Page  8 

(United  States  Department  of  Defense  2008b),  (United  States  Department  of  Defense 
2010a) 

Page  9 

(United  States  Navy  2011),  (United  States  Department  of  Defense  2008a),  (United  States 
Congress/United  States  Government  1996) 

Page  10 

(United  States  Department  of  Defense  Joint  Chiefs  of  Staff  2007b),  (United  States 
Department  of  Defense  Joint  Chiefs  of  Staff  2007a),  (United  States  Department  of 
Defense  Joint  Chiefs  of  Staff  20 13), (United  States  Department  of  Defense  2008a;  United 
States  Department  of  Defense  2004),  (United  States  Department  of  Defense  2007c) 
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Page  1 1 

(United  States  Navy  2009a),  (United  States  Navy  2006b),  (United  States  Navy  2006c), 
(United  States  Department  of  Defense  2009),  (United  States  Congress/United  States 
Government ,  901-904) 

Page  12 

(United  States  Congress/United  States  Government  2006) ,  (United  States  Department  of 
Defense  2005), (United  States  Air  Force  2002), (United  States  Department  of  Defense 
20 10b), (United  States  Department  of  Defense  1977), 

Page  13 

(United  States  Navy  2006b), 

Page  14 

(INSITU  -  Michael  Tucker  2011),  (United  States  Navy  2011),  (United  States  Department 
of  Defense  2008c) 

Page  15 

(United  States  Department  of  Defense  2008b), (United  States  Navy  2011),  (United  States 
Navy  1998), (United  States  Department  of  Defense  2008a)(United  States  Navy  2011) 
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Component  Analysis  and  Attribute  Investigation:  Certification  Justification  of  Payload 

Integration  Checklist 

SAFETY  COMPONENTS 

The  following  certifications,  as  shown  in  Figure  37,  satisfy  the  Safety  system 
requirements: 


Figure  37:  Safety  Certifications 

Airworthiness  Certification 

Statutory/Regulatory  Airworthiness  Requirement 

Airspace,  regardless  of  sovereignty  or  elevation,  will  always  be  expected  to  be 
shared  among  a  variety  of  aircraft  (public,  civil,  and  private).  Because  of  this,  steps  must 
be  taken  to  ensure  the  safe  operation  of  aircraft  that  navigate  through  the  same  airspace 
and  to  protect  property/personnel  on  the  ground.  This  is  imposed  through  a  statutory 
requirement,  Title  49  United  States  Code  (USC),  Sec  40103  -  Sovereignty  and  Use  of 
Airspace. 
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NAVAIR  Airworthiness  Certification  Process 


For  aircraft  (manned  and  unmanned)  that  is  owned/  and/or  operated  by  or  for  the 
U.S.  Navy,  this  is  satisfied  by  an  accomplished  through  a  NAVAIR  airworthiness 
certification  called  a  Flight  Clearance  per  NAVAIRINST  13034. ID.  This  document  is 
designed  to  ensure  that  operation  of  the  specifically-configured  system  can  be  performed 
within  acceptable  standards  of  loss  of  life  and/or  damage  to  property  or  the  environment. 
It  is  developed  by  the  PMA,  in  coordination  with  the  applicable  SMEs  and  NAVAIR’ s 
Airworthiness  Office  (Air  4. OP). 

RAIN  is  concerned  with  payloads  affected  by  rapidly-changing  UAS 
technologies.  This  requires  an  airworthiness  certification  process  that  is  flexible  and  can 
quickly  incorporate  new  capabilities.  A  NAVAIR  interim  flight  clearance  (IFC)  is  well- 
suited  to  this  requirement  because  it  can  be  generated  in  as  little  as  a  few  weeks  or  up  to 
20  weeks,  depending  on  complexity  of  the  system.  There  is  no  cost  for  this  certification 
since  the  labor  hours  are  already  included  in  the  PMA  budget.  It  is  developed  by  the 
platform’s  Assistant  Program  Manager  for  Systems  Engineering  (APMSE),  in 
coordination  with  the  applicable  SMEs,  and  approved  for  release  by  NAV AIR’s 
Airworthiness  Office  (Air  4. OP). 

Airworthiness  Waivers/Interim  Approval  Request 

No  waivers  are  authorized  for  airworthiness  certifications;  but  IFCs  can  be 
released  to  obtain  additional  data  in  support  of  relaxing  previous  operating  limitations 
and  restrictions. 

Battery  Certification 

Statutory/Regulatory  Battery  Requirement 

Lithium  (Li)-ion  batteries  are  utilized  in  a  variety  of  equipment  throughout  the 
U.S.  Navy  due  to  their  ability  to  provide  high  voltage  and  long  life.  Unfortunately,  these 
inherent  attractive  characteristics  also  make  these  batteries  highly  susceptible  to 
overheating,  which  could  cause  ruptures  and  explosions.  This  has  resulted  in  the 
establishment  of  the  Navy’s  Lithium  Battery  Safety  Program,  as  per  NAVSEAINST 
93 10.  IB,  to  mitigate  the  dangers  associated  with  the  utilization  of  these  particular  power 


sources. 
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NAVAIR  Battery  Certification  Process 

Through  this  program,  any  Li-ion  battery  that  will  be  employed  in  any  U.S.  Navy 
equipment  must  be  certified  by  NOSSA  prior  to  initial  fielding.  This  certification  process 
will  be  conducted  by  the  PMA,  in  coordination  with  NAV AIR’s  Propulsion  and  Power 
competency  (AIR  4.4. 5. 2).  If  no  testing  is  required,  a  battery  can  be  certified  for 
installation  into  a  specific  platform  within  a  couple  of  weeks  and  at  a  cost  of  $3K  for 
documentation  expenses.  A  lack  of  OEM  data  will  require  complex  testing,  thus 
increasing  the  certification  process  duration  to  26  weeks  and  costing  the  PMA  $80K. 
Battery  Waivers/Interim  Approval  Request 

No  waivers  are  authorized  for  a  battery  certification;  but  interim  approvals  may  be 
granted  for  limited  duration.  For  these  interim  approval  requests,  documentation  (e.g., 
Universal  Need  Statement  (UNS))  must  be  provided  that  justifies  the  need  to  operate  with 
uncertified  batteries  before  NOSSA  completes  their  analysis. 

Laser  Certification 

Statutory/Regulatory  Laser  Requirement 

The  Department  of  Navy  uses  a  variety  of  LASERs  to  complete  its  mission.  The 
use  of  LASERs  are  regulated  under  Title  21,  Code  of  Federal  Regulations  (CFR),  Parts 
1040,  1040.10,  and  1040.11.  These  regulations  dictate  both  how  LASERs  can  be  built 
and  used,  and  are  focused  at  the  civilian  sectors.  For  the  military  to  effectively  use  its 
LASERs,  the  CFR  Regulations  are  further  decomposed  and  refined  by  DoD  Instruction 
6055.15,  which  is  further  decomposed  by  OPNAVINST  5100. 27B.  Since  DoD  LASER 
employments  are  significantly  different  from,  and  potentially  more  dangerous  than,  the 
civilian  sector,  the  DoN  has  established  the  Navy  Laser  Hazards  Control  Program. 
NAVAIR  Laser  Certification  Process 

There  are  three  (3)  basic  parts  to  the  Navy  LASER  certification  process.  The 

process  is  controlled  by  the  LASER  Safety  Review  Board  (LSRB),  which  holds  final 

certification  authority  within  the  Navy  and  USMC.  The  first  phase  of  an  LSRB  approval 

is  to  issue  a  Military  Exemption  Letter  to  the  manufacturer  for  the  specific  laser  being 

procured.  Once  this  letter  is  obtained  a  LASER  radiation  hazard  evaluation  must  be 

completed  in  accordance  with  the  LASER  Characterization  Test  Report  (ANSI  Z136.4, 
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Recommended  Practice  for  Laser  Safety  Measurements  for  Hazard  Evaluation),  this  test 
is  usually  conducted  by  a  DoD  lab,  with  a  cost  ranging  from  $10K  to  $20K.  Including 
lead  times,  the  characterization  should  take  between  four  (4)  and  10  weeks.  Upon 
successful  completion  of  the  LASER  characterization  a  Design  Checklist  5100.27B  for 
the  LASER  system  should  be  completed,  based  on  the  characterization  of  the  LASER,  a 
system  safety  measure,  and  the  user  mission.  Although  the  LSRB  meets  once  a  month, 
requests  to  present  LASERs  for  certification  must  be  submitted  two  (2)  months  in 
advance.  The  LSRB  review  and  subsequent  approval  letter  can  be  completed  in  two  (2)  to 
four  (4)  weeks. 

Laser  Waivers/Interim  Approval  Request 

LSRB  waivers  are  not  authorized,  but  interim  approvals  can  be  obtained  during 
system  development.  These  interim  approvals  follow  the  standard  certification  process, 
but  are  designed  to  allow  incremental  increases  in  LASER  use  to  support  testing  and 
safely  develop  the  system. 

Weapon  Certification  (Weapons  System  Explosives  Safety  Review  Board- WESRB) 
Statutory/Regulatory  Weapon  Requirement 

The  WSESRB  was  created  via  regulation  in  1968  in  response  to  explosives  related 
mishaps  aboard  aircraft  carriers.  Because  safety  is  not  common  sense,  the  WSESRB 
provides  independent  oversight  to  ensure  maximum  compliance  with  system  explosives 
safety  requirements.  The  WSESRB  responsibilities,  authorities,  and  operation  procedures 
are  issued  by  NAVSEAINST  8020. 6D  and  apply  to  all  Navy  systems.  The  WSESRB 
authority  chain  is  as  follows: 

DoDI5000.2  Para  E7.7 

•  PM  shall  identify,  evaluate  and  manage  safety  and  health  hazards. 

•  Explains  the  process  for  accepting  risk 

SECNAVINST  5000.2C 

•  CNO  may  establish  system  safety  advisory  boards. 

SECNAVINST  5 100.1  OH 
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•  Directs  Chief  of  Naval  Operations  (CNO)/Commandant  of  the  Marine  Corps 
(CMC)  to  establish  safety  programs. 

OPNAVINST  8020.14  /  Marine  Corps  Order  (MCO)  P8020.1 1 

•  Explosives  Safety  Policy 

•  Tasks  COMNAVSEASYSCOM  to  establish  WSESRB 
NAVSEAINST  8020.6D 

•  Defines  WSESRB  process  and  procedures 

NAVAIR  Weapon  Certification  Process 

The  range  of  issues  of  concern  related  to  explosives  include:  Hazard 
Classification,  Insensitive  Munitions,  Final  (Type)  Qualification  of  Energetics,  Lithium 
Battery  Certification,  and  Human  Systems  Integration.  The  WSESRB  reviews  system 
designs,  provides  concurrence  or  non-concurrence  with  system  design,  recommends 
design  changes,  concurs  or  non-concurs  with  PM  risk  assessments.  Each  program  has  a 
WSESRB  POC  who  is  to  facilitate  interactions  between  the  program  and  the  WSESRB. 
The  WSESRB  POC  follows  the  procedures  detailed  in  NAVSEAINST  8020.6D  to 
request  a  review  of  a  system  by  the  board.  A  board  representative  informs  the  POC  when 
the  board  can  review  the  system. 

A  program  representative  and  the  WSESRB  POC  attend  a  meeting  of  the 
WSESRB  to  brief  the  system.  The  board  confers  and  issues  its  findings.  If  the  board  finds 
that  there  is  residual  risk  it  may  not  concur  with  the  design  and  recommend  design 
changes.  Residual  risk  may  be  accepted  by  the  program;  but  any  residual  risk  assessments 
must  be  concurred  with  by  the  WSESRB  and  accepted  at  the  appropriate  level:  High 
Risk  =  Assistant  Secretary  of  the  Navy  (ASN)  Research  Development  and  Acquisition 
(RDA),  Serious  Risk  =  PEO,  Moderate/Low  Risk  =  PM.  Usually  multiple  reviews  are 
required. 

Weapon  Waivers/Interim  Approval  Request 

The  recommendations  of  the  WSESRB  can  be  waived  by  having  the  associated 
residual  risk  accepted  at  the  appropriate  level.  The  assessment  of  residual  risk  must  be 
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concurred  with  by  the  WSESRB.  The  appropriate  level  for  accepting  residual  risk  is  as 

follows:  High  Risk  =  ASN  (RDA),  Serious  Risk  =  PEO,  Moderate/Low  Risk  =  PM. 

There  are  no  interim  approvals. 

System  Safety  Certification 

Statutory/Regulatory  System  Safety  Requirement 

Imposed  under  statutory  requirement,  the  system  safety  standard  practice  MIL- 

STD-882  ascertains  DoD’s  methodology  for  identifying  and  assessing  Environmental, 

Safety,  and  Occupational  Health  (ESOH)  hazards  as  well  as  mitigating  ESOH  risks 

confronted  during  integration,  testing,  fielding,  operation,  and  disposal  of  defense 

systems  if  applied.  The  approach  shall  be  compliant  with  DoDI  5000.02. 

NAVAIR  System  Safety  Certification  Process 

With  commitment  to  ensure  safety  of  defense  systems,  public  property,  and 

organizational  resources  from  accidental  destruction,  damage,  or  environmental  impacts 

and  to  protect  private  and  public  personnel  from  accidental  loss,  injury,  or  occupational 

illness,  a  system  safety  approval  is  essential  in  managing  and  minimizing  ESOH  risks 

related  to  DoD  systems.  The  System  Safety  Risk  Assessment  (SSRA)  process  should  be 

applied  appropriately  based  on  the  ESOH  disciplines  to  identify  hazards  and  mitigate 

associated  risks  throughout  the  SE  process  for  any  defense  system,  including  integrating 

and  fielding  even  tested  modular  payloads  with  new  or  existing  technology  development. 

The  system  safety  risk  assessment  process  consists  of,  but  not  limited  to, 

establishing  an  ESOH  hazard  analysis,  operator’s  and  maintainer’s  manuals  with 

appropriate  cautions  and  warnings,  system  safety  engineering  plan,  hazardous  materials 

management  plan  (HMMP),  Programmatic  Environmental,  Safety,  and  Health  Evaluation 

(PESCHE),  system-of-system  integration  and  interoperability  hazard  analysis,  Failure 

Mode  Effects  and  Criticality  Analysis  (FMECA)  or  other  reliability  data,  and  any  fault 

tree  analysis.  It  will  also  include,  if  applicable,  Hazards  of  Electromagnetic  Radiation  to 

Personnel  (HERP)  and  Hazards  of  Electromagnetic  Radiation  to  Fuel  (HERF) 

calculations,  NOSSA  approval  of  lithium  batteries  and  Material  Safety  Data  Sheet 

(MSDS),  and  all  other  system  safety  related  documents.  In  order  to  obtain  an  approval  for 

system  safety,  a  System  Safety  Risk  Assessment  (SSRA)  should  be  processed  and 
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approved  by  PMA  within  one  (1)  to  26  weeks,  with  a  cost  ranging  from  $3k  to  $5  Ok, 
depending  on  the  complexity  of  the  system. 

System  Safety  Waivers/Interim  Approval  Request 

No  interim  approval  and  waivers  are  authorized  for  system  safety  certification. 
According  to  MIL-STD-882,  “ESOH  hazards  shall  be  identified  and  assessed,  and  ESOH 
risks  shall  be  mitigated  and  accepted  in  accordance  with  DoD  policy.”  { {36  United  States 
Department  of  Defense  2000}}. 

Range  Safety  Certification 
Statutory/Regulatory  Range  Safety  Requirement 

According  to  NAVAIR  Instruction  3700.3  paragraph  4a,  “DoDD  3200.11 
establishes  the  policy  for  operations  and  administration  of  DoD  test  and  evaluation 
(T&E)  facilities  designated  as  Major  Range  and  Test  Facility  Bases  (MRTFB)  and 
designates  the  Range  Commander  as  responsible  for  safety  on  each  MRTFB  range.”  { {77 
United  States  Navy  2007}}.  Paragraph  4b  of  the  same  instruction  states  the  requirement 
that  “the  NAVAIR  Range  Department,  consisting  of  three  (3)  MRTFB  range  sites, 
requires  a  unified  approach  for  range  safety”  {{77  United  States  Navy  2007}}.  For 
purposes  of  consistency  and  the  effectiveness  of  range  safety  programs  at  each  site,  all 
sites  shall  implement  common  policies.  Any  deviation  from  policies  will  be  limited  to 
those  necessitated  by  site -unique  missions,  capabilities  or  constraints.”  Further  details  on 
range  safety  are  found  in  Naval  Air  Warfare  Aircraft  Division  (NAWCAD)  Instruction 
3710. 1A. 

NAVAIR  Range  Safety  Certification  Process 

Range  Safety  is  concerned  with  many  of  the  same  issues  as  the  System  Safety 

community,  but  specifically  in  the  context  of  operating  the  system  in  and  T&E  range 

environment.  The  test  range  environment  has  different  system  stressors  and  additional 

concerns  that  may  not  be  present  in  the  operational  environment.  These  special 

requirements  must  be  addressed  to  ensure  safety  of  defense  systems,  public  property,  and 

organizational  resources  from  accidental  destruction,  damage,  or  environmental  impacts 

and  to  protect  private  and  public  personnel  from  accidental  loss,  injury,  or  occupational 

illness  on  or  around  a  test  range.  Range  Safety  approval  builds  on  the  work  done  to 
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obtain  System  Safety  and  IFC  approvals.  The  NAVAIR  range  safety  office  (AIR-5.2.3)  is 
responsible  for  the  review  and  approval  of  range  safety-related  portions  of  test  plans, 
determining  project  support  requirements  are  in  concert  with  established  command 
policy,  and  providing  day-to-day  policy  interpretation.  Range  Safety  Officers  (RSO)  are 
tasked  with  ensuring  that  no  unnecessary  risk  is  accepted  by  the  range. 

In  order  to  aid  in  obtaining  approval  of  a  test  plan  from  the  RSO,  it  is  crucial  that 
it  includes  containment  of  all  hazards,  avoids  single  point  failures,  and  categorizes  all 
risks  that  the  equipment  may  present  to  the  range  and  its  personnel  along  with  its 
mitigating  steps.  Risks  should  be  identified  as  early  as  possible  during  the  process  of 
writing  the  test  plan.  Standard  operating  procedures  for  handling  such  risks  must  be 
written  and  established.  Training  must  be  given  to  personnel  who  are  operating  the 
equipment  on  such  risks,  with  any  go/no-go  criteria  established  prior  to  operation. 

The  range  safety  risk  assessment  process  consists  of,  but  is  not  limited  to, 
reviewing  the  hazardous  materials  management  plan  (HMMP);  Programmatic 
Environmental,  Safety,  and  Health  Evaluation  (PESCHE);  system-of-system  integration 
and  interoperability  hazard  analysis;  Electromagnetic  Environmental  Effects  Integration 
Analysis  Report  (E3IAR)  and  associated  verification  reports;  Hazards  of  Electromagnetic 
Radiation  to  Personnel  (HERP)  and  Hazards  of  Electromagnetic  Radiation  to  Fuel 
(HERF)  calculations;  Hazards  of  Electromagnetic  Radiation  to  Ordnance  (HERO)  (on  the 
system  as  well  on  other  systems  exposed  to  the  system);  the  findings  of  the  WSESRB; 
NOSSA  approval  of  lithium  batteries  and  Material  Safety  Data  Sheet  (MSDS);  and  all 
other  system  safety  related  documents.  Additional  information  that  may  be  required 
includes,  but  is  not  limited  to,  hazard  pattern  analyses,  system  design  descriptions,  system 
operation  descriptions,  and  test  plans.  Exact  requirements  will  be  based  on  the  system 
design  and  operation  descriptions,  test  plan,  and  discussions  between  the  RSO,  test 
engineers  and  PMA.  Once  the  required  information  needs  is  submitted,  a  determination 
will  usually  be  made  within  four  (4)  weeks,  with  cost  dependent  on  the  complexity  of  the 
system. 

Range  Safety  Waivers/Interim  Approval  Request 
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There  are  no  formal  range  safety  waivers.  Similar  to  System  Safety,  hazards  shall 
be  identified  and  assessed,  and  ESOH  risks  mitigated  and  accepted  in  accordance  with 
DoD  policy.  All  risks  to  the  range  or  people  on  or  around  the  range  must  be  approved  by 
the  RSO,  who  is  the  cognizant  point  of  contact  if  any  questions  arise  about  any  particular 
situations  in  regards  to  range  issues  related  to  risks. 

Electromagnetic  Environmental  Effects  (E3)  Certification 
Statutory/Regulatory  E3  Requirement 

Electromagnetic  radiation  permeates  the  environments  of  the  modem  battlefield 
and  the  modem  test  range.  In  order  to  ensure  the  safe  and  correct  operation  of  military 
electronic  systems,  the  DoD  directs  the  services  to  address  E3  concerns  in  DoDD  3222.3. 
The  Navy  implements  that  directive  through  SECNAVINST  2400.0,  SECNAVINST 
5000.2,  OPNAVINST  2400.20,  and  NAVAIRINST  2400.1.  The  procedures  and 
standards  to  be  used  to  comply  with  these  regulations  are  MIL-STD-464,  MIL-STD-461, 
MIL-HDBK-23 5 ,  and  NAVAIR  16-1-529. 

E3  is  concerned  with  the  negative  or  unintended  effects  of  the  electromagnetic 
environment  on  both  the  system  of  interest  and  the  systems  with  which  it  interacts.  All 
electrical  systems  produce  electromagnetic  signals  that  can  travel  via  both  radiation  and 
conduction,  and  potentially  cause  unintended  unsafe  malfunctions  of  the  system  of 
interest  or  other  external  systems.  Because  of  this,  system  designs  must  adequately 
protect  the  system  from  the  environment  and  protect  external  systems  from  its  emissions. 
Both  analysis  and  test  are  used  to  determine  if  the  system  has  adequate  protections  to 
ensure  safe  operation  in  its  intended  environments.  Up  to  thirteen  analyses  and 
certifications  may  be  required  that  “encompasses  the  electromagnetic  effects  addressed 
by  the  disciplines  of  electromagnetic  compatibility  (EMC),  electromagnetic  interference 
(EMI),  electromagnetic  vulnerability  (EMV),  electromagnetic  pulse  (EMP),  electronic 
protection  (EP),  electrostatic  discharge  (ESD),  and  hazards  of  electromagnetic  radiation 
to  personnel  (HERP),  ordnance  (HERO),  and  volatile  materials  (HERF).  E3  includes  the 
electromagnetic  effects  generated  by  all  electromagnetic  environment  (EME)  contributors 
including  radio  frequency  (RF)  systems,  ultra-wideband  devices,  high-power  microwave 
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(HPM)  systems,  lightning,  precipitation  static,  etc.”  {{42  United  States  Air  Force 

2010}}. 

NAVAIR  E3  Certification  Process 

The  first  step  is  the  E3  Integration  &  Analysis  Report  (E3IAR),  which  details  the 
tailoring  of  the  requirements  in  MIL-STD-464C  &  MIL-STD-461F  for  the  system  of 
interest  by  providing  a  rationale  to  conduct  testing  or  not  for  each  requirement. 
Additionally,  a  Radiation  Hazard  (RADHAZ)  analysis  may  be  required.  Depending  on 
the  findings  from  the  E3IAR  and  RADHAZ  analysis,  the  below  compliance  certifications 
may  be  required: 


•  EMC 

•  EMI 

•  EMP 

•  EMY 

•  ESD 

•  HERF 

•  HERO 

•  HERP 

•  Bonding  &  Grounding 

•  Lighting 

•  Precipitation  Static  (P-Static) 

“Within  NAVAIR,  Electromagnetic  Environmental  Effects/Spectrum 
Supportability  (E3/SS)  approval  and  enforcement  is  the  responsibility  of  the 
Electromagnetic  Environmental  Effects  Division,  (AIR-4.1.13).”  (NAVAIRINST  2400.1 
2009,  p.3) 

E3  Waivers/Interim  Approval  Request 

Waivers  may  be  granted  for  most  of  the  E3  certifications  by  the  CNO,  except  for 
HERO  testing,  which  can  be  waived  by  NOSSA  through  the  WSESRB.  Interim 
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certifications  do  not  apply,  but  systems  that  do  not  fully  comply  with  certifications 
regarding  radiated  emissions  may  be  subjected  to  minimum  standoff  distances  from  other 
systems,  fuel,  or  people. 

SECURITY  COMPONENTS 

The  following  certifications,  as  shown  in  Figure  38,  satisfy  the  Security  system 
requirements: 


Figure  38:  Security  Certifications 

Information  Assurance  (IA)  Certification 

Statutory/Regulatory  IA  Requirement 

Information  Assurance  (IA)  provides  a  secure,  interoperable,  net-centric 
Information  Management  (IM)/Information  Technology  (IT)  environment  across  the 
Department  of  Navy  (DoN)  Enterprise.  All  DoN  information  and  Information  Systems 
(ISs)  are  serious  to  maintaining  our  naval  control  and  national  security.  To  ensure 
adequate  protection  for  our  information  assets,  DoD  Information  Assurance  Certification 
and  Accreditation  (C&A)  Process  (DIACAP)  evaluates  the  defense-in-depth  layering  of 
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IA  principle  and  control  to  people,  processes,  and  technology  by  following  the  DoDI 
8500.0 IE,  DoDI  8500.2,  and  DoDI  8510.01  guidelines. 

NAVAIR  Information  Assurance  (IA)  Certification  Process 

The  SME  from  AIR  7.2.6  submits  a  DoD  IA  Certification  (DIACAP)  package  to 
the  Operational  Designated  Accrediting  Authority  (ODAA)  for  an  Authorization  to 
Operate  (ATO).  Although  collection  of  the  required  data  and  performance  of  the 
vulnerability  scans  can  be  completed  in  30  to  60  days,  review  of  the  DIACAP  package  by 
the  ODAA  can  take  up  to  52  weeks. 

I A  Waivers/Interim  Approval  Request 

No  waivers  are  authorized  for  IA  certification.  An  Interim  Authority  to  Test 
(IATT)  may  be  issued  by  the  Designated  Accrediting  Authority  (DAA)  (NAVAIR  Chief 
Information  Officer  -  CIO)  or  an  Interim  Authority  to  Operate  (IATO)  may  be  issued  for 
use  of  the  system  for  a  limited  time  while  identified  security  weaknesses  are  addressed. 
Anti-Tamper  (AT)  Certification 
Statutory/Regulatory  AT  Requirement 

Anti-Tamper  (AT)  involves  activities  to  prevent  and/or  delay  exploitation  of 
critical  technologies  in  U.S.  weapon  systems.  These  activities  involve  the  entire  life-cycle 
of  systems  acquisition,  including  research,  design,  development,  implementation,  and 
testing  of  AT  measures.  To  prevent  unapproved  technology  transfer,  alteration  of  system 
competency,  or  countermeasure  development,  program  protection  may  require  anti¬ 
tamper  capabilities,  which  are  a  derivative  of  the  security  engineering  process.  The  AT 
process  is  addressed  under  DoDI  5000.2,  DoDI  5200.39,  and  AT  Guideline  Version  2 
(the  guideline  is  mapping  of  DoD  Information  Assurance  Certification  and  Accreditation 
Process  DIACAP  to  IA  Controls)  to  complete  and  obtain  an  AT  certification. 

NAVAIR  AT  Certification  Process 

The  SME  from  AIR  4.1.14  submits  the  AT  plan  and  the  Critical  Program 
Information  (CPI)  Identification  and  Critical  Analysis  assessment  to  the  Anti-Tamper 
Executive  Agent  (ATEA).  The  AT  certification  shall  be  conducted  in  accordance  with 
ATEA.  The  duration  and  cost  to  obtain  AT  certification  is  dependent  on  Development 
Test  (DT). 
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AT  Waivers/Interim  Approval  Request 

No  waivers  are  authorized  for  AT  certification;  but  interim  approvals  may  be 
issued  by  the  ATEA  for  a  limited  time  while  the  approval  package  is  pending. 

Selective  Availability  Anti-Spoofing  Module  fSAASM)  GPS  Certification 

Statutory/Regulatory  SAASM  GPS  Requirement 

DoD  GPS  Security  Policy  issued  in  2006  mandates  all  newly  fielded  DoD  GPS 
systems  deploy  SAASM-compliant  Precise  Positioning  System  (PPS)  devices  due  to  the 
need  for  improving  GPS  security.  Receivers  without  SAASM  have  a  higher  risk  of 
dropping  GPS  signal  due  to  spoofing  or  jamming,  which  would  result  in  the  loss  of 
precise  location  and  increase  the  time  required  to  synchronize  over  communications 
systems.  SAASM  utilizes  anti-spoofing  and  anti-jamming  measures  through  encryption 
and  keys  to  protect  authorized  receivers  from  operating  with  false  satellite  signals 
generated  intentionally  or  unintentionally  by  allies  or  enemy.  Although  government 
regulations  require  all  the  latest  DoD  GPS  systems  to  incorporate  SAASM  GPS  receiver 
cards  to  increase  security  of  crypto  keys  and  counteract  spoofing,  many  federal  agencies 
and  military  groups  still  employ  non-SAASM  GPS  receivers  that  put  them  in  a  higher 
security  risk.  Since  standard  GPS  service  can  be  rejected  at  any  time  via  tactical  combats, 
such  as  spoofing  and  jamming,  it  will  be  a  challenge  for  non-SAASM  GPS  receivers  to 
correct  the  situation  quickly. 

NAVAIR  SAASM  GPS  Certification  Process 

All  requests  for  NAVAIR  SAASM  GPS  Certification  are  processed  and  approved 
by  the  GPS  Directorate  (GPSD),  including  Security  Approval  for  SAASM  Host 
Application  Equipment  (HAE)  and  SAASM  Design  Requirements  for  HAE. 

SAASM  GPS  Waivers/Interim  Approval  Request 

Integrating  non-SAASM  GPS  requires  a  waiver,  which  can  be  authorized  by 
Assistant  Secretary  of  Defense.  However,  no  waiver  is  obtained  for  Security  Approval  for 
SAASM  HAE  and  SAASM  Design  Requirements  for  HAE  (SAASM  Functionalities, 
including  Extended  Functions). 

Clinger-Cohen  Act  (CCA) 

Statutory/Regulatory  CCA  Requirement 
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Clinger-Cohen  Act  (CCA)  has  reformed  and  improved  the  way  the  Navy  acquires 
and  manages  Information  Technology  (IT)  resources.  An  approved  Acquisition 
Information  Assurance  (IA)  Strategy  is  mandatory  for  systems  that  are  or  have  IT  when 
determined  to  be  Mission  Critical  and  Mission  Essential.  The  CIO  will  be  responsible  for 
developing,  maintaining,  and  facilitating  the  implementation  of  a  sound  and  integrated  IT 
architecture  under  USC  Title  40  Subtitle  III  and  Office  of  Management  and  Budget 
(OMB)  Circular  A-ll  Appendix  J  {{53  United  States  Department  of  Defense  2008}}, 
{ {35  United  States  Navy  2011}}. 

NAVAIR  CCA  Certification  Process 

The  SME  from  AIR  7.2.6  (CCA  Center  of  Excellence  (COE))  provides  an 
executive  summary,  in  addition  to  the  statutory  and  regulatory  documentation,  to  the 
NAVAIR  CIO.  The  CCA  Compliance  Table  must  be  populated  with  the  Milestone 
Decision  Authority  (MDA)  specified  program  governing  documentation  and  an 
Acquisition  IA  Strategy.  There  is  no  test  related  to  CCA.  CCA  certification  for 
Acquisition  Category  (ACAT)  III  and  below  can  be  achieved  in  32  days,  with  the  cost  as 
low  as  $6K.  ACAT  I  &  II  would  take  an  additional  three  (3)  months  due  to  review  by  the 
second  echelon,  for  a  cost  of  $5  IK. 

CCA  Waivers/Interim  Approval  Request 

No  waivers  or  interim  approvals  are  authorized  for  CCA  certifications. 

INTEROPERABILITY  COMPONENTS 

The  following  certifications,  as  shown  in  Figure  39,  satisfy  the  Interoperability 

system  requirements: 
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Figure  39:  Interoperability  Certifications 

Interoperability  Certification 

Statutory/Regulatory  Interoperability  Requirement 

Joint  interoperability  supports  the  U.S.  Navy’s  and  DoD’s  mission  to  have  net- 
centric  systems  that  ensure  clear  communication  among  all  military  systems,  thus 
enhancing  the  warfighter’s  capabilities.  In  an  excerpt  from  DoDI  5000.2,  Enclosure  6, 
Paragraph  2-C-8: 

“All  DoD  Major  Defense  Acquisition  Programs  (MDAPs),  programs  on  the  OSD  T&E 
Oversight  list,  post-acquisition  (legacy)  systems,  and  all  programs  and  systems  that  must 
interoperate,  are  subject  to  interoperability  evaluations  throughout  their  life  cycles  to 
validate  their  ability  to  support  mission  accomplishment.  For  IT  systems  (including 
Network  Security  Services  (NSS))  with  interoperability  requirements,  the  Joint 
Interoperability  Test  Command  (JITC),  regardless  of  AC  AT,  shall  provide  system 
interoperability  test  certification  memorandums  to  the  Deputy  Under  Secretary  of 
Defense  (Acquisition  and  Technology)  (Deputy  Undersecretary  of  Defense 
(DUSD)(Acquisition  and  Technology  (A&T)),  the  Assistant  Secretary  of  Defense 
(ASD)(NII)/Department  of  Defense  Chief  Information  Officer  (DoD  CIO),  and  the 
Director,  Joint  Staff  J-6,  throughout  the  system  life-cycle.”  {{56  United  States 
Department  of  Defense  2008}} 
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NAVAIR  Interoperability  Certification  Process 

The  JITC  representative  for  the  PMA  is  responsible  for  identifying  the  required 
certification  level  for  a  given  stage  in  the  development  and  fielding  of  the  payload. 
With  all  the  necessary  architecture  views,  a  limited  interoperability  certification  can  be 
obtained  in  two  (2)  to  three  (3)  months,  with  full  certification  in  an  additional  three  (3) 
months. 

Interoperability  Waivers/Interim  Approval  Request 

No  waivers  are  authorized  for  interoperability  certification.  A  limited 
interoperability  certification  may  be  obtained  for  purposes  of  testing  and  training,  but  full 
certification  is  required  for  an  Initial  Operational  Capability  (IOC)  decision. 

Spectrum  Certification 

Statutory/Regulatory  Spectrum  Requirement 

Assigning  electromagnetic  radio  frequencies  for  a  variety  of  defense  systems  such 
as  satellites,  radio,  or  radars  on  the  ever-diminishing  electromagnetic  spectrum  is  a 
critical  process.  With  the  rapidly-changing  nature  of  current  tactics,  more  complex 
defense  systems  rely  on  the  spectrum  to  acquire  information  superiority  and  guide 
advanced  weapons,  especially  unmanned  systems.  To  be  compliant,  DoD  has  established 
policies  and  guidance  to  obtain  spectrum  certification  imposed  through  a  statutory 
requirement,  Title  47  U.S.  Code  §305,  §901-904.  To  ensure  that  communication 
equipment  operating  within  an  intended  environment  meet  standard  rules,  guidelines, 
regulations,  and  limitations,  National  Telecommunications  and  Information 
Administration  (NTIA)  has  established  the  Spectrum  Certification  Process. 

NAVAIR  Spectrum  Certification  Process 

Spectrum  certification  requests  shall  be  submitted  by  the  SME  from  AIR  4.1.M.1 
to  the  NTIA  in  the  Equipment  Location-Certification  Information  Database  (EL-CID) 
format.  The  process  should  take  about  nine  (9)  to  208  weeks,  with  the  cost  ranging  from 
$2k  to  $48k,  depending  on  certification  and  complexity  of  the  systems. 

Spectrum  Waivers/Interim  Approval  Request 
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No  waivers  are  authorized  for  spectrum  certifications.  However,  interim 
approvals  may  be  granted  with  submission  to  the  Spectrum  Planning  Subcommittee 
(SPS)  or  the  local  NTIA  Authority  for  limited  duration. 

Common  Data  Link  (CDL) 

Statutory/Regulatory  CDL  Requirement 

H.R.1815  National  Defense  Authorization  Act  for  Fiscal  Year  2006  mandates  all 
datalinks  used  by  UAS  shall  be  CDL  compliant.  The  Act  is  further  clarified  by  ASD 
Memo  Dec  30  2005  Subject  DoD  CDL  Policy,  which  amplifies  the  importance  of  CDL 
for  UAS  video  Datalinks,  and  exempted  UAS  under  30  Lbs. 

CDL  is  a  family  of  government-developed  and  -owned  communication 
waveforms.  Under  the  new  Bandwidth  Efficient  -  CDL  (BE-CDL)  waveforms  and 
Standard  CDL  Rev  H  waveforms,  users  have  a  selection  of  frequency  bands  in  which 
they  may  operate,  including  S-Band,  C-Band,  Ku-Band,  and  X-Band.  The  CDL  family 
also  utilizes  a  common  and  interoperable  encryption  schema  that  includes  both  Suite  A 
and  Suite  B.  The  purpose  of  the  CDL  family  is  to  reduce  development  and 
interoperations  cost  of  proprietary  radio  systems  and  increase  user  interoperability  by 
using  a  common  communication  schema. 

NAVAIR  CDL  Certification  Process 

For  the  certification  package  it  is  submitted  by  SME  from  AIR  4.5  to  the  CDL 
executive  agency.  It  is  presented  to  the  CDL  executive  agency  the  Systems  Engineering 
Technical  Review  (SETR)  milestone  review. 

NAVAIR  CDL  Waivers/Interim  Approval  Request 

Interim  CDL  waivers  can  be  obtained,  if  certain  requirements  are  met  and  a  long¬ 
term  plan  to  obtain  CDL  is  developed,  funded,  and  exercised.  A  CDL  waiver  will  take  26 
to  104  weeks,  if  the  waiver  process  is  begun  with  all  of  the  required  justification 
substantiated  upfront.  To  successfully  obtain  a  CDL  Waiver,  it  must  be  demonstrated  that 
utilizing  CDL  would  prevent  the  system  from  completing  its  mission.  The  Waiver  must 
be  routed  to  the  Assistant  Secretary  of  the  Navy  for  Research,  Development,  and 
Acquisition  (ASN  RDA),  Assistant  Secretary  of  Defense  for  Networks  and  Information 

Integration  (ASD  Nil),  the  Office  of  the  Secretary  of  Defense  (OSD),  and  the  DoD  CIO. 

407 


To  begin  this  waiver  process,  a  program  should  meet  with  their  branch’s  CDL  Executive 
Office  to  determine  feasibility  and  identify  the  correct  stakeholders. 

COMPATIBILITY  COMPONENTS 

The  following  certifications,  as  shown  in  Figure  40,  satisfy  the  Compatibility 
system  requirements: 


ffbd  Determine  Compatibility  Certifications 


STUAS  Project 


Organization: 

Naval  Postgraduate  School  (.. 


J  uly  20,  2013 


Figure  40:  Compatibility  Certifications 

Environmental  Certification 

Statutory/Regulatory  Environmental  Requirement 

Materials  are  the  building  blocks  of  an  aircraft  and  react  based  upon  the 
environment.  They  need  to  operate  within  different  environments;  they  need  to  provide  a 
degree  of  protection  from  the  environment  to  survive  each  mission  profile  and  the 
physical  asset  needs  to  have  degree  of  durability.  This  relates  directly  to  reliability, 
availability,  maintainability,  longevity  and  cost.  This  requirement  is  outlined  in 
SECNAVINST  5000.2E  and  specifically  states  in  section  6.1.5  that  each  ACAT  I 
program  shall  document  its  corrosion  prevention  and  control.  While  any  program  other 
than  an  ACAT  I  does  not  need  a  corrosion  prevention  and  control  plan,  it  is  advised  to  aid 
in  meeting  regulatory  requirements  for  example  the  Hexavalent  Chromium  DFARS 
2252.223-7008  that  requires  the  control  or  elimination  of  the  use  of  hexavalent 
chromium  from  weapons  platforms.  Hexavalent  Chromium  is  primarily  found  in  the 
coatings  and  materials  that  make  up  the  platform,  of  which  the  performance  and  use  are 
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found  in  the  corrosion  prevention  and  control  plan.  The  corrosion  prevention  and  control 
plan  (CPC)  also  outlines  the  specific  testing  that  will  be  performed  as  found  in  MTL- 
STD-810.  Thus,  based  upon  the  materials  of  construction  and  the  environment  that  the  air 
vehicle  will  see,  specific  tests  are  chosen  to  prove  the  performance  and  effect  on  the  life 
cycle  of  the  aircraft. 

Typically  the  Contractor  shall  develop  and  implement  a  Corrosion  Control  Plan 
(CCP)  for  the  system  using  the  DoD  Corrosion  Prevention  and  Control  Planning 
Guidebook  Spiral  No.  3  of  Sep  2007  (Ref  Section  3.2.11)  as  a  guide  to  ensure  corrosion, 
wear,  and  erosion  resistance  is  considered  in  the  Contractors  design  of  the  system.  The 
Contractor  shall  develop,  utilize,  and  maintain  a  CPC  Plan  and  shall  establish,  participate 
in,  and  support  a  Corrosion  Prevention  and  Control  (CPC)  Advisory  Team  jointly  with 
the  Government  to  track  the  progress  of  CPC  engineering  efforts. 

NAVAIR  Environmental  Certification  Process 

To  meet  the  air  vehicle  (AV)  and  air  worthiness  requirements  the  materials  and 
processes  of  protection  requirements  apply  to  both  structural  and  non-structural  materials 
and  applications  used  for  the  AV.  The  AV  environmentally-degraded  properties  shall 
account  for  exposure  to  any  natural  and  induced  environment  reflecting  authorized  usage, 
storage,  and  maintenance  throughout  the  service  life  of  the  AV.  The  AV  environmentally 
degraded  properties  shall  account  for  representative  production  processing, 
manufacturing  variability,  final  assembly  interfaces,  life  cycle  exposure,  and  the  supplier 
base.  Specific  tests  from  MIL-STD-810  and  others  are  selected 

The  AV  and  its  component  parts  shall  be  finished  In-Accordance-With  (IAW) 
MIL-STD-7179  the  environmental  certification  process  for  each  air  vehicle  platform  is 
outline  in  the  specific  Corrosion  Control  Plan  (CCP).  The  CCP  details  the  tailoring  of  the 
requirements  of  MIL-STD-810  to  the  system  of  interest  by  providing  a  rationale  to 
conduct  testing  to  meet  the  operational  environment  and  materials  compatibility. 
Depending  on  the  value  of  the  payload,  mission  requirements,  and  funding  environmental 
performance  tests  below  may  be  required  to  comply  with  the  certification: 
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•  Humidity  (48hrs) 

•  Salt  Atmosphere  (48hrs) 

•  Dust  Test 

•  Rain  Test 

•  High  Temperature  Operational  &  Non-Operational 

•  Internal  Operational  Temperature 

•  Low  Temperature  Operational  &  Non-Operational 

•  Temperature  Change 

•  Shock  per  MIL-STD  -810G  Methods  for  flight,  launch,  recovery,  & 
transportation,  equipment/payload  per  MIL-S-901D 

•  Vibration  per  MIL-STD-810G  Methods  for  flight,  launch,  recovery  & 
transportation,  equipment/payload  per  MIL-STD- 167-1 A 

Within  NAVAIR,  Environmental  approval  and  enforcement  is  the  responsibility 
of  the  Materials  Engineering  Division,  (AIR-4.  3.4)  and  the  PMA-263  Systems  Engineer. 
Payloads  are  generally  certified  for  shock  and  vibration  via  a  certification  provided  by  the 
Contractor,  if  the  testing  is  performed  at  all.  Since  the  programs  are  not  ACAT  I,  they  are 
not  required  to  have  a  CCP  and  test  for  environmental  durability  thus  this  requirement  is 
advisory  for  durability  risks. 

Environmental  Waivers/Interim  Approval  Request 

The  environmental  performance  testing  certification  is  part  of  the  Flight 
Clearance  documentation  and  the  requirement  can  be  waived.  The  agreement  to  waive 
these  requirements  for  payloads  is  coordinated  by  the  cognizant  Corrosion  Engineer  and 
Senior  Materials  Engineer  from  AIR  4.3.4  Materials  Engineering  Division  and  PMA-263 
Systems  Engineer  with  the  PMA-263  management. 

Test  &  Evaluation  (T&E) 

Statutory/Regulatory  T&E  Requirement 
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The  test  program  will  be  managed  by  the  AIR  5.0  T&E  representative  at  the 
PM  A.  A  Test  Project  Worksheet  will  be  submitted  to  the  T&E  representative  requesting 
testing  of  the  desired  platform,  with  the  required  objectives  and  timeframe.  If  necessary, 
the  T&E  representative  will  coordinate  with  the  external  test  agency  for  OT&E  and 
submit  reports  for  approval  to  the  Director  of  OT&E.  The  level  of  complexity  of  the 
required  test(s)  will  determine  the  cost  and  duration. 

NAVAIR  T&E  Certification  Process 

T&E  is  invaluable  to  the  development  and  fielding  of  new  capabilities  to  the 
warfighter.  It  is  utilized  to  determine  the  technical  maturity  level  of  the  system,  identify 
deficiencies  that  need  to  be  corrected,  and  provide  technical  risks  to  assist  the  decision¬ 
makers.  Developmental  test  and  evaluation  (DT&E)  focuses  on  system  requirements  and 
the  system  level  risk,  while  operational  test  and  evaluation  (OT&E)  is  concerned  with  the 
capability  the  system  delivers  to  the  soldier,  the  operational  risks,  and  how  the  system 
performs  in  its  intended  environment  (paraphrased  from  the  DAG5000.02  enclosure  6). 
This  is  imposed  through  a  statutory  requirement,  Department  of  Defense  Directive 
(DoDD)  5000.1,  The  Defense  Acquisition  System. 

T&E  Waivers/Interim  Approval  Request 

OT&E  is  required  for  all  major  defense  acquisition  programs,  as  defined  in  Title 
10  USC  2340  -  Major  Defense  Acquisition  Program  and  thus,  cannot  be  waived. 

Combined  DT&E  and  OT&E  is  authorized  when  schedule  and  cost  savings  can  be 
justified.  This  integrated  test  program  must  allow  for  separate  evaluations  from  the 
developmental  and  operational  communities. 
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APPENDIX  I. 


PAYLOAD  INTEGRATION  SCHEDULE 


Payload  Integration  Checklist  for  PMA-263  in  MS  Project®  Worse  Case  Longest 

Schedule 

Schedule  for  All  Certifications  in  Checklist  using  RAIN  Model  Data  for  All 

Certifications 

(Start  7/23/13  end  1 1/22/17  approximately  4  years  4  months  corresponds) 

The  Payload  Integration  Schedule  is  a  product  of  the  RAIN  Team  Research  and  is  a 
deliverable  item  to  PMA-265  for  future  integration  projects. 
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APPENDIX  J.  RAIN  IPR  MEETING  NOTES 


Ronnie  Lyliston 

RAIN  IPR  #1: 

21  March  2013 

Attendees: 

Wayne  Parsons 

Dr.  Rama  Gehris 

Bonnie  Young 

Angel  Perez 

Chris  Ironhill 

Fred  Lancaster 

Diana  Ly 

Bryan  Otis 

Luis  Conde-Santos 

Nam  Tran 

Notes: 

Questions  and  Information  (FYI’s)  from  Brigitte  T.  Kwinn 

The  U.S.  Army  has  tactical  UAVs,  have  you  looked  at  what  the  Army  does? 

•  We  did  check  with  the  Army  (PM  UAS).  They  don’t  have  a  documented  process, 

either. 

What  other  SE  processes  did  you  consider?  Why  did  you  select  the  V  model  instead  of 
another  model? 

•  V  model  was  selected  because  it’s  the  process  of  choice  throughout  NAVAIR  and 

would  be  readily-accepted  by  our  Sponsors.  We  did  consider  other  models 
including  the  DAU  waterfall  model  and  the  one  from  SE3100  but  we  like  the 
‘Vee’  model  better  because  of  the  explicit  and  linear  verification  connection 
between  the  definition  and  decomposition  products  and  the  integration  and 
decomposition  products  that  the  ‘Vee’  model  affords. 

You  have  identified  system  inputs  and  outputs;  did  you  consider  establishing  input  or 
output  requirements?  Why? 

•  We  did  consider  establishing  input  and  output  requirements,  and  we  plan  on  doing 

that.  The  requirements  are  dependent  on  research  that  we  have  not  finished  yet. 
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Have  you  identified  any  other  functions  for  the  system? 

•  We  have  not  agreed  on  the  system  functional  hierarchy  yet. 

17  top  level  system  requirements  is  a  pretty  large  number,  typically  there  are  about  10 
that  deal  with  the  system  inputs,  system  outputs,  system  functions,  system  interfaces  and 
the  “ilities.” 

•  Actually,  we  only  have  four  top-level  system  requirements:  Interoperability, 

Safety,  Security,  and  Suitability/Environmental  Compatibility. 

The  17  are  the  Component-level  requirements  that  were  derived  from  the  System-level 
requirements. 

•  There  are  only  two  stakeholder  level  requirements,  or  four  System  level 

requirements  (see  slide  28).  What  is  listed  in  the  requirements  research  matrix 
are  the  component  level  and  configuration  item  level  requirements. 

FYI  2:  You  can  do  the  requirements  tracing  and  management  in  CORE  also,  it  will 
capture  the  same  info  you  have  in  your  matrix  on  page  33 

•  We  are  using  CORE®.  The  matrix  is  just  for  tracking  research  based  on  the 

requirements. 

Second  Reply  from  Bridgette  Quinn 

Make  sure  you  emphasize  that  the  Army  doesn’t  have  a  process  either,  this  makes 
what  you  are  doing  that  much  more  important. 

Your  process  has  to  fit  your  system  and  system  life  cycle  that  is  why  there  are  so 
many  processes.  The  V  is  a  system  development  process  not  a  process  for  system  process 
creation.  That  doesn’t  mean  you  can’t  use  it  but  you  must  have  evidence  why  it  fits  what 
you  are  doing. 

Your  4  top  system  level  requirements  are  the  “ilities”?  You  don’t  have  any 
capability/function  requirements?  What  must  the  system  do  not  what  must  the  system  be? 

You  don’t  have  to  answer  this  second  round  of  questions. 

End  of  notes. 
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RAIN  IPR  #2: 

06  June  2013 

Attendees: 

Benjamin  Teich 

Wayne  Parsons 

Vincent  Tolbert 

Dr.  Paul  Montgomery 

Dr.  Rama  Gehris 

Prof.  Bonnie  Young 

Fred  Lancaster 

Angel  Perez 

Bryan  Otis 

Chris  Ironhill 

Diana  Ly 

Luis  Conde-Santos 

Notes: 

Nam  Tran 

Wayne  Parsons; 

Clinger  Cohen  Act,  statutory  requirement,  some  clarification  since  it  applies  to  automated 
data  equipment,  does  it  apply? 

•  It(data)  drives  a  lot  of  security  issues. 

The  DRM  he  thought  it  was  out  of  scope  specifically  T&E. 

•  T&E  is  an  external  interface.  T&E  is  conducted  by  T&E  facilities  and 

organizations  where  PMA-263  is  a  customer 
Dr.  Gehris: 

Is  there  any  one  system  that  is  really  worse  case?  Obtaining  all  certifications  for 
example? 

•  SME’s  take  weeks  to  review  on  the  WESRB  Board  only  meet  at  certain  times  and 

creates  a  backlog  and  the  longest  pole  is  security. 

Dr.  Montgomery: 

Trying  to  craft  a  process  of  what  is  called  RAIN,  do  you  have  a  model  of  what  is  the 
current  process? 

•  Ad  hoc  process  does  not  exist. 
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No  process  where  schedule  &  risk  trade  use  case  certification  process  vectors  to  trade  risk 
and  schedule,  only  data  in-house/ad  hoc.  So  some  use  case  ma  take  36  months  but  now 
there  is  structure. 

Problem  statement  is  not  “what  we  are  doing,”  hearing  no  way  to  assess  what  we  are 
doing  against  a  variety  of  scenarios. 

•  Process  instead  of  method. 

•  Slide  103  is  sorted  by  work  time,  but  both  wait  time  and  cycle  time  is  there  as 

well. 

Top  title  has  to  do  with  rapid  integration  of  stuff,  appears  just  trading  off  certification  of 
stuff? 

Sounds  like  interoperability  analysis. 

•  All  things  needed  to  get  to  the  warfighter  get  to  be  interoperable. 

What  do  you  envision  the  product  and  what  do  you  think  it  is? 

Sounds  3 -dimensional,  still  don’t  see  the  light  at  the  end  of  the  tunnel. 

•  NAVAIR  has  a  bunch  of  procedures  but  there  isn’t  a  process  in  place  for  all  of  the 
procedures.  This  process  organizes  and  maps  out  the  requirements  via  architecture 
using  CORE  and  then  simulates  the  process  of  procedures  in  iGraphx.  (Dr.  Gehris 
-  the  project  is  the  process,  Bonnie-  not  a  method  but  a  process)  bringing  a 
process  to  procedures  -  this  will  be  brought  out  up  front  in  the  report. 

End  of  \notes 
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1  Introduction 


1 . 1  Project  Background 

The  Department  of  the  Navy  (DoN)  maintains  a  relatively  small  inventory  of  Small 
Tactical  Unmanned  Aircraft  Systems  (STUAS).  These  systems  are  designed  to  be  highly 
modular  and  support  multiple  configurations,  allowing  for  user  selection  of  payloads  based  on 
unique  mission  needs.  This  modularity  reduces  the  necessity  for  multiple  unique  Unmanned 
Aircraft  Systems  (UAS)  platforms  and  their  associated  life  cycle  costs,  while  still  providing 
mission  flexibility.  Technology  developers  have  been  successful  in  designing  new  payloads 
which  integrate  into  the  UAS  platform  and  meet  mission  requirements.  This  provides  a 
technology  that  is  at  a  suitable  Technology  Readiness  Level  (TRL),  meets  all  technical 
requirements  of  a  particular  UAS  Interface  Control  Document  (ICD),  and  size,  weight,  and 
power  (SWAP)  requirements,  but  does  not  address  the  DoN  System-level  requirements  for 
integration  and  fielding. 

It  is  the  responsibility  of  the  systems  integrator  to  ensure  that  the  platform,  with  its  new 
payload,  meets  all  regulatory  and  statutory  requirements  for  deployment  to  the  fleet.  This  is 
done  by  obtaining  the  necessary  technical  certifications  (e.g.,  laser,  Li  battery,  airworthiness 
approvals)  imposed  by  regulatory  requirements  on  the  systems.  An  example  of  a  statutory 
requirements  placed  on  UAS,  which  must  be  addressed  for  successful  integration,  is  H.R1815 
National  Defense  Authorization  Act  for  Fiscal  Year  2006  (HR  Bill,  2005),  which  states  all  data 
links  used  by  an  UAS  must  use  the  government  developed  Tactical  Common  Data  Link  (TCDL). 
This  particular  example  has  caused  challenges  in  the  past  because  some  payloads  are  developed 
with  their  own  Command  and  Control  (C2)  data  links,  so  they  do  not  have  to  integrate  with  the 
existing  UAS  data  links,  reducing  the  complexity  of  integration.  Unfortunately  if  the  payload  is 
not  developed  to  the  TCDL  requirement,  this  piece  of  the  payload  has  to  be  re-engineered  to 
complete  systems-level  integration. 

The  transition  process  between  integration  of  the  payload  into  the  target  platform  and  its 
ultimate  integration  into  the  encompassing  DoN  System  is  not  well-defined.  Each  DoN  System 
level  requirement  is  handled  by  a  different  organization  within  the  government,  where  the 
knowledge  of  that  particular  process  and  its  associated  requirements  is  self-contained.  To  date, 
little  effort  has  been  made  to  take  a  systems-level  approach  to  bridge  those  lines  of 
communication  between  organizations  and  collect  all  that  information  into  one  readily-accessible 
repository. 

This  elongates  the  timeline  and  creates  new  technical  challenges  between  the  integration 
of  a  payload  and  the  fielding  of  a  new  UAS  capability.  With  the  current  undefined  process  once 
a  payload  is  delivered  for  integration  into  the  system  it  takes  approximately  24  to  36  months, 
depending  on  complexity  of  the  effort,  to  thoroughly  satisfy  all  the  applicable  statutory  and 
regulatory  requirements  before  the  system  can  be  inducted  into  the  DoN  inventory.  This 
timeframe  is  unacceptable  in  supporting  the  rapidly-evolving  environment  to  which  our  war- 
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fighters  are  exposed.  For  the  sake  of  expediency  the  integration  timeline  is  often  shortened  by 
waiving  or  inadvertently  overlooking  the  systems-level  requirements  without  an  understanding 
of  technical  risk  in  these  decisions,  resulting  in  a  rapidly-fielded  system  that  may  be  technically 
insufficient  to  meet  mission  needs  and  could  pose  substantial  risks  to  the  warfighters  in  the 
future.  To  address  these  technical  challenges  and  reduce  the  integration  timeline,  systems 
engineers  must  capture  trade-offs  that  provide  leadership  with  option  to  balance  cost,  schedule, 
and  performance  risk  to  the  program. 

1.2  Project  Management  Plan  Purpose 

The  purpose  of  this  Project  Management  Plan  (PMP)  is  to  outline  the  approach  the  RApid 
INtegration  (RAIN)  Team  will  take  to  address  current  short-comings  in  integration  and  fielding 
new  capabilities  on  STUASs. 

1.3  Problem  Statement 

The  Department  of  the  Navy  (DON)  does  not  have  a  documented  process  that  maintains 
sufficient  Systems  Engineering  (SE)  discipline  to  rapidly  integrate  and  field  new  mission 
configurations  for  their  inventory  of  modular  STUAS  to  the  fleet  to  support  aggressive  schedules 
and  urgent  user  needs  in  a  timeframe  of  six  to  18  months  instead  of  the  typical  24  to  36  months 
while  minimizing  technical  risk  to  mission  success.  The  requirements  for  whether  or  not  to 
perform  each  certification  (sub  process)  in  the  current  process  are  not  well  understood  and  are 
often  addressed  in  a  reactive  fashion,  sometimes  when  identified  as  the  entry  criteria  for  a 
different  certification  or  approval 

1.4  Problem  Scope 

The  scope  of  this  project  will  be  limited  to  new  capabilities  that  can  be  integrated  into 
modular  STUAS  in  the  existing  PMA  263  inventory.  The  candidate  payloads  will  be  limited  to 
those  that  meet  the  technical  requirements  of  the  platform's  ICD  and  will  not  require  re-design  of 
the  UAS  or  modification  of  the  current  airframe. 

1.5  Project  Goals 

The  goal  of  this  project  is  to  create  and  document  a  comprehensive  process  for  the  integration  of 
new  capabilities  of  modular  UAS  into  the  DoN  System,  then  conduct  a  SE  trade  study,  similar  to 
an  Analysis  of  Alternatives  (AoA),  to  address  the  UAS  systems  integration  challenges  outlined 
in  section  1.1.  The  trade  study’s  goal  will  be  to  find  the  best  way  to  rapidly  integrate  and  field 
new  configurations,  meet  technical  requirements,  balance  technical  risk,  and  produce  options  for 
a  rigorous  SE  process  that  can  be  tailored  to  meet  program  needs. 

1.6  Project  Deliverables 

The  goal  of  this  project  is  to  conduct  a  trade  study  of  a  comprehensive  SE  plan  to  address 
payload  integration  of  DoN  requirements  onto  PMA-263  STUAS  platforms.  To  complete  this 
study  a  documented  process  to  facilitate  integration  and  fielding  of  new  capabilities  must  be 
developed.  The  documented  process  will  be  used  for  modeling  and  simulation  of  the  systems 
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integration  process.  The  final  trade  study  will  allow  a  tailoring  of  systems-level  integration 
requirements  to  support  the  rapid  integration  and  fielding  of  UAS  capabilities  into  the  DoN 
System.  The  following  deliverables  will  be  produced  to  support  this  analysis,  and  contained 
within  the  final  report. 

1.7.1  Project  Management  Plan 

The  Project  Management  Plan  (PMP)  will  contain  the  approach  and  process  the  Team 
will  use  to  address  the  problem  statement  and  conduct  the  trade  study. 

1.7.2  Project  Schedule 

The  project  schedule  will  address  the  timing  and  execution  of  the  PMP;  it  will  include  a 
Microsoft  Project  schedule  that  addresses  delivery  dates  and  detailed  work  flow. 

1.7.3  Systems  Engineering  Plan 

The  Systems  Engineering  Plan  (SEP)  will  provide  the  details  of  the  project  execution  and 
the  templates  used  to  conduct  the  trade  study.  The  plan  will  include,  but  is  not  limited  to,  the 
following  subject  areas: 

•  Body  (Note:  this  is  not  an  all  inclusive  list) 
o  SE  Approach 
o  Risk  Management 

o  Specialty  Areas  (Note:  this  is  not  an  all  inclusive  list) 

■  Security 

■  Information  Assurance 

■  Spectrum  Management 

■  Anti  Tamper 

■  Software 
o  Test  Planning 

o  Requirements  Management 
o  Project  Architecture 

The  SEP  will  also  include  the  following  items  as  tools  to  conduct  the  trade  study. 

1. 7. 3. 1  Integration  Ch  ecklist 

The  Integration  Checklist  will  provide  a  detailed  list  of  all  system-level  SE  work  that 
needs  to  be  addressed  to  properly  integrate  a  new  capability.  Each  item  in  the  list  will  address  its 
purpose  and  deliverables.  The  goal  of  this  list  is  to  capture  the  systems-level  requirements  for 
payload  integration  that  will  drive  the  trade-off  analysis. 

It  will  also  provide  a  technology  developer  the  information  needed  to  scope  and  execute 
comprehensive  integration  of  their  payload  to  support  timely  fielding.  This  checklist  will  flow 
into  the  cost  and  schedule  templates  and  provide  the  typical  cost  and  time  needed  to  perform 
each  item  based  on  interactions,  internal  and  external,  to  PM  A  263. 
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/.  7, 3, 2  Sck  e&ilt  Template 

The  schedule  template  will  be  used  to  determine  schedule  impacts  while  conducting  the 
trade-off  analysis.  It  will  be  based  on  Lhe  systems  level  requirements  derived  for  the  integration 
check  list. 

It  could  he  also  a  Parting  point  for  future  work  that  could  provide  the  technology 
developer  a  scheduling  tool  to  assist  in  lhe  development  of  each  efforts  required  work  and 
execution  plan,  based  on  the  applicable  integration  items  from  the  checklist. 

1,7.4  Trade-off  Analysis  Results 

The  trade-off  Analysis  results  will  be  a  summary  oi'the  conclusions  derived  from 
incorporating  and  analyzing  the  variables  captured  with  in  this  project’s  scope 


2  t'l  ojt-cr  Oi  fl  jni/atbm  Lind  Pint  lei  punts 


2,1  hi}jw1  Oi  guni/uliori 


Figure  I.  Team  Organization 


2AA  Project  Lead 

'Lhe  Project  l.ead  far  this  project  will  be  Mr.  Bryan  < Jiis.  He  will  provide  overall 
management  and  leadership  for  the  RAIN  Team.  The  Lead  will  organize  and  run  all  Team 
meetings  and  represent  the  Team  as  the  interface  to  Project  Advisors,  Stakeholders,  and 
Sponsors,  He  will  be  responsible  for  ensuring  the  Team  maintains  schedule  and  provides 
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deliverables  on  time.  The  lead  will  also  manage  Team  assignments,  actions,  and  any  issues  that 
arise  over  the  project.  He  will  provide  project  directions  and  ensure  the  Team  functions 
smoothly,  addressing  any  inter-Team  challenges. 

2.1.2  Deputy  Project  Lead 

The  Deputy  Project  Lead  lor  this  project  will  be  Ms.  Angel  Perez.  She  will  support  the 
project  lead  as  they  provide  overall  management  and  leadership  lor  the  RAIN  Team.  The  Deputy 
will  assist  with  organizing  and  running  all  Team  meetings  and  represent  the  Team  as  the 
interface  to  Project  Advisors,  Stakeholders,  and  Sponsors.  She  will  be  responsible  for  ensuring 
the  Team  maintains  schedule  and  provides  deliverables  on  time  when  the  project  lead  is 
unavailable.  The  Deputy  will  also  assist  with  the  management  of  Team  assignments,  actions,  and 
any  issues  that  arise  over  the  project.  She  will  work  with  the  project  lead  to  determine  project 
directions  and  ensure  the  Team  functions  smoothly,  addressing  any  inter-Team  challenges. 

2.1.3  Modeling  &  Simulation  Lead 

The  Modeling  &  Simulation  (M&S)  Lead  for  this  project  is  Mr.  Christopher  (Chris) 
Ironhill.  He  will  be  responsible  for  the  division  and  management  of  M&S  products  assigned  by 
Team  leadership,  among  the  M&S  working  group.  For  the  RAIN  project,  the  M&S  Lead  will  be 
responsible  for  providing  models  of  the  current,  the  “to-be”,  and  the  transitional  states  of  the 
system  and  processes  involved  in  integrating  a  payload  onto  a  STUAS.  Additionally,  he  will 
conduct  verification  and  validation  (V&V)  that  the  models  adequately  represent  reality  to  ensure 
that  they  will  produce  reliable  data. 

2.1.4  Architecture  Lead 

The  Architecture  Lead  for  this  project  is  Mr.  Nam  Tran.  He  will  be  responsible  for  the 
basic  structure  development  of  the  rapid  payload  integration  and  fielding  of  STUAS,  defining  the 
essential  schema  through  Department  of  Defense  Architecture  Framework  (DoDAF)  artifacts. 

2.1.5  Editorial  Lead 

The  Editorial  Lead  for  this  project  is  Mr.  Fred  Lancaster.  He  will  oversee  the  written 
products  by  collecting  and  editing  Team  members'  written  inputs  project  briefs  and  compiling 
and  tracking  references  using  RefWorks®.  When  editing  the  team's  writing  inputs  he  will 
conduct  a  technical  writing  review  to  ensure  consistency,  document  flow,  formatting,  references, 
and  the  final  product's  writing  quality.  lie  will  work  with  Team  leadership  to  assign  report 
sections  and  set  up  reviews  of  each  Team  member’s  work. 

2.1.6  Risk  Manager 

The  Risk  Manager  for  this  project  is  Mr.  Luis  Conde.  He  will  be  responsible  for 
identifying  and  analyzing  project  and  product  risks  and  their  subsequent  tracking  and  managing. 
For  the  RAIN  project,  the  Risk  Manager  will  develop  the  Risk  Management  Plan  template  and 
process,  which  will  be  delivered  in  the  SEP.  The  Risk  Manager  will  be  responsible  for 
communicating  with  all  Stakeholders  and  Team  members  about  the  risks,  performing  the  risk 
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analysis,  and  approving  the  ri&k  mitigation  plan.  It  is  his  responsibility  to  ensure  tiiat  all  risks 
have  been  adequately  mitigated  or  that  plans  are  in  place  prior  to  proceeding  past  the  respective 
milestone  reviews. 

2,1,7  Requirements  Manager 

The  Requirements  Manager  for  this  project  is  Mr.  Chris  Ironhill.  lie  will  be  responsible 
for  ;ithe  identification,  derivation,  allocation,  and  control  in  a  consistent,  traceable,  correctable, 
verifiable  manner  of  all  the  system  functions,  attributes,  interfaces,  and  verification  methods” 
that  the  RAIN  “system  must  meet  including  customer,  derived  (internal),  and  specialty 
engineering  needs.”  [[  (Buede,  1999)194]. 

2,L8  C  onfiguration  Manager 

The  Configuration  Manager  for  this  project  is  Mr.  1  ,uis  Conde.  He  will  be  responsible 
for  the  configuration  management  of  Team  deliverables  and  will  work  closely  with  the  Lead 
Editor, 

2.1.9  Cost  Estimator 

The  Cost  Estimator  for  this  projeet  is  Ms.  Diana  Ly.  She  will  be  responsible  for 
developing  the  model  to  conduct  cost  estimation  of  rapid  payload  integration  and  fielding.  She 
will  identify  cost  estimates  of  system,' Tune  Lion  al  requirements  by  developing  models  based  on 
collected  data  within  scope  of  this  project. 

2.1*10  Scheduler 

The  Scheduler  for  this  project  is  Mr.  Fred  Lancaster.  He  w  ill  be  responsible  for  managing 
the  schedule  of  the  RAIN  Team’s  project.  He  will  work  with  Team  leadership  to  outline  projeet 
timelines  and  product  delivery  dates.  Mr.  Lancaster  will  also  be  responsible  for  leading  the 
Team  in  developing  the  scheduling  model  to  support  the  necessary  events  and  timelines  of 
conducting  tailorable  payload  integration  on  to  a  STUAS. 

2.2  ("ummuniuitions 

Team  members  will  coordinate  individual  Integrated  Project  Team  (IPT)  events  and  work 
via  email  and  the  Sakai  website  to  post  work  products  and  project  deliverables.  The  Team  will 
utilize  Elluminate  Live  during  non- working  hours  and  Defense  Connect  Online  (DCO)  with  a 
dedicated  photic  bridge  during  working  hours,  as  shown  in  Table  1  and  fable  2. 


Table  1.  Meeting  Resources 

Resources 

Link 

KNuni  unite  live 

Individuals  Saki  site 

Defense  Connect  Online 

https :/ /connect  dc  o .  dod.mil  ,'r3  5 7826 1 0 

Dedicated  Phone  Bridge 

1-866-214-2635 

Meeting  Number: 

*2949314* 
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Table  2*  Buttle  Rhythm 


Meeting  Type 

rime  and  Location 

Duration  &  Purpose 

Core  Project  Team  and 
Advisor  Meetings 

Thursday  1700-2000  FST, 
Elluminate 

1  to  3  Hours  Advising 
meeting,  work  review,  and 
Strategy  meeting 

Team  Meeting 

Friday  1500- 1600  EST, 
DCO  and  Phone  Bridge 

1  Hour  -  weekend 
assignments  and  strategy 
meeting 

Working  Croup* 

Sunday  Flexible  times, 
Elluminate 

1  to  2  hours  working  groups 
time 

Team  Meeting 

Monday  1500  1600  EST, 

DCO  and  Phone  Bridge 

1  Hour  work  review,  weekly 
assignments,  and  strategy 
meetings 

2*3  Capstone  Advisors 

Iliere  are  two  advisors  for  this  project: 

•  Dr.  Rama  Gohris 

Dr,  Gehris  has  a  PhD  in  SK  and  has  taught  at  Naval  Postgraduate  School  (NPS)  since 
2011.  She  has  also  served  as  an  advisor  on  four  Capstone  projects. 

•  Professor  Bonnie  Young 

Professor  Young  has  a  MS  in  SE  and  is  working  on  her  PhD.  She  has  taught  at  NPS 
since  20 1 1  and  served  as  an  advisor  on  five  capstone  projects. 

2*4  Stakeholders 

The  project  stakeholders  are  identified  below  and  shown  in  Figure  2.  Each  project 
stakeholder  interfaces  with  each  other  and  the  RAIN  team  to  help  guide  and  scope  the  project, 
subject  to  RAIN  advisors  concurrence.  The  Stakeholders  can  he  broken  down  in  to  three  main 
groups,  as  listed  below,  and  are  further  decomposed  in  Figure  2.  While  main  stakeholders  exist, 
when  categorized  into  three  groups  each  group's  interests  are  the  same.  The  RAIN  team’s 
primary  interest  is  in  completing  a  Capstone  project  that  both  shows  the  students’  mastery  of 
Systems  Engineering,  while  producing  a  useful  product  to  other  stakeholders.  PMA-263\s 
primary  interest  is  to  implement  a  rapid  system  integration  process,  while  maintaining  systems 
engineering  rigor.  Ilie  External  stakeholders’  primary  interest  is  in  rapidly  fielding  new 
technology,  while  reducing  risk  to  technical  challenges. 

*  RAIN  Team 

*  Students 

*  Project  Advisors 
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*  PM  A  263: 


*  Chief  Engineer 

*  Weapon  Systems  Integration  IPT  I  ,ead 
•  Configuration  Manager 

*  External  Stakeholders: 

*  APEO  (U&W)  Engineering 

*  Warfighters 

*  Requirements  Officers 

*  Technology  developer 


External  stakeholders,  identified  in  the  list  below,  all  hold  interest  in  the  results  of  this 
project’s  trade  study  analysis.  Each  stakeholder  interacts  with  the  RAIN  team  and  each  other, 
conceptualized  in  a  cloud  formation  below  ill  Figure  3.  PMA-263  is  interested  in  the  risks  with 
different  implementation  options  of  the  systems  engineering  process  to  complete  capabilities 
integration.  Individual  platform  IPT  leads  will  be  interested  in  what  options  lliey  have  when 
implementing  an  integration  effort,  and  howr  their  decisions  will  affect  a  systems  engineer’s 
ability  to  maintain  rigor  while  executing  a  program  plan.  The  Requirements  officers  and  end 
users  stake  in  this  project  revolve  around  delivering  the  end  product.  The  technolog}  developer’s 
interest  is  the  ability  to  rapidly  integrate  and  deliver  their  products,  while  maintaining  systems 
engineering  rigor  to  reduce  risk  of  future  teclmieal  challenges. 

*  PM  A  263 

*  Platform  IPT  Lead 

*  Requirements  Officers 


Page  14  of  34 


432 


•  Platform  Integrators 

•  Technology  developers 

•  Warfighters/End  Users 


Figure  3.  External  Stakeholders 


2.5  Subject  Matter  Experts  (SME) 

Subject  matter  expertise  for  this  project  will  be  provided  by  the  following: 

•  PM  A  263  Advance  Development  IPT  Lead 

•  PEO(U&W)  Chief  Airworthiness  Engineer  (Unmanned  &  Weapons) 

•  PMA  263  Air-Ship  Integration  Lead 

•  PMA  263  E3  Technical  Authority  Expert  (TAE) 

•  PMA  263  Product  Support  Manager 

•  Spectrum  Management  Support 

•  I ,aser  Safety  Review  Hoard  (I  ,SRB)  Chair 

•  Weapon  Systems  Explosive  Safety  Review  Board  (WSESRB), 

•  PMA  263  Program  Protection  Lead 

•  PMA  263  System  Safety  TAE 

•  Naval  Ordinance  Safety  and  Security  Activity  (NOSS  A) 

•  Joint  Interoperability  Test  Command  (JITC) 

•  PMA-263  Training  TAE 

•  PMA  263  Test  and  Evaluation  (T&E)  IPT  Lead 


3  Systems  Engineering  Approach 
3.1  Systems  Engineering  Process 

The  Team  will  utilize  the  Forsberg  and  Mooz  “Vee”  Development  Model,  shown  in 
Figure  4?  as  the  basis  of  our  SE  approach,  to  execute  the  CAPSTONE  project  due  to  its  common 
utilization  throughout  NAVAIR.l  (FHA,  2013)]  Iliis  model  begins  with  the  identification  of 
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Stakeholders*  needs  in  the  lop  left,  with  the  design  oi  l  he  product  continuing  down  the  lell  side 
ofthewVee"  The  right  side  of  tlie^Vee11  involves  the  actual  development  and  verification  of  the 
product,  resulting  in  el  final  product  HielI  is  validated  by  the  user  at  Hie  top  right 


Figure  4,  Forsbcrg  &  Moor  "Vee*  Development  Model  for  SE  Approach 


The  team  tailored  this  model  as  applicable  tortile  development  of  a  process  rather  than  a 
tangible  system,  as  shown  in  figure  5  since  no  hardware  will  be  designed  nor  developed  for  this 
project.  This  process  will  produce  the  project  deliverables  outlined  in  Section  6. 


Figure  5.  Tailored  Process 

Similar  to  the  base  LlVee”  SE  approach,  an  initial  analysis  of  the  Stakeholders'  needs  will 
be  conducted.  This  will  result  in  the  formulation  of  top-level  requirements.  An  analysis  of  those 
requirements  will  then  form  the  foundation  of  the  preliminary  payload  integral  ion  process,  which 
will  lead  Su  the  detailed  process  development.  This  will  conclude  the  Definition  and 
Decomposition  phiise  of  the  “Vce”  approach. 
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Integration  and  Re-composition  will  begin  with  the  establishment  of  a  model  to  simulate 
execution  of  the  developed  process.  Using  this  model,  the  RAIN  Team  will  examine  several 
options  that  will  reduce  implementation  time,  to  address  urgent  user  needs,  of  the  process  while 
minimizing  risk  to  the  user.  ITie  high,  medium,  and  low  cost  estimates  will  be  captured  and  used 
as  another  factor  in  the  analysis.  Further  investigation  will  enable  the  development  of  a  more 
detailed,  comprehensive  process.  Upon  the  identification  of  viable  alternatives,  they  will  be 
demonstrated  to  the  Stakeholders  and  published  in  the  final  report  for  the  project. 

3.1.1  Stakeholder  &  Needs  Analysis 

The  purpose  of  a  Needs  Analysis  is  to  develop  a  comprehensive  description  of  the  nature 
of  the  problem.  This  begins  with  determining  what  the  Stakeholders  want  and  formulating  the 
initial  problem  statement.  The  desired  needs  are  then  organized  and  prioritized  based  on  the 
Stakeholders'  stated  level  of  importance. 

The  Stakeholders  were  be  interviewed  to  ascertain  the  problems  and  frustrations  they 
have  encountered  when  attempting  to  Held  a  new  payload  into  existing  platforms.  This  provided 
a  better  understanding  as  to  what  issues  are  causing  delays  in  the  lidding  process,  resulting  in 
the  initial  problem  statement.  The  needs  obtained  from  the  interviews  were  then  analyzed  to 
further  refine  the  problem  statement  and  provide  focus  for  the  project. 

These  dialogues  will  determine  what  requirements  are  most  important  to  the  Stakeholders 
and  will  define  what  aspects  of  the  process  are  inflexible.  This  will  be  used  to  develop  the  initial 
Measures  of  Effectiveness  (MOE)  and  systems  boundaries,  assumptions  and  constraints.  They 
will  also  identify  where  the  schedule  can  be  reduced,  depending  on  the  Stakeholders'  w  illingness 
to  accept  risk  in  terms  of  type  (cost,  schedule,  technical)  and  level  (lowr,  medium,  high).  These 
negotiable  areas  will  form  the  space  to  conduct  a  trade-off  analysis  for  an  optimal  process 
allowing  the  Stakeholders  to  rapidly  field  a  new  payload. 

3.1.2  Requirements  Analysis 

Requirements  will  be  gathered  from  the  Stakeholders,  internal  and  external,  of  the 
payload  integration  process.  Assumptions  and  constraints  will  be  captured  and  identified  as 
such.  Once  gathered,  the  requirements  w  ill  be  analyzed  for  conflicts  and  feasibility. 
Requirements  conflicts  will  be  brought  to  the  Stakeholders  for  clarification.  Documented 
statutory  and  regulatory  requirements  will  be  assumed  to  override  other  requirements.  If 
statutory  and  regulatory  requirements  conflict  with  end  user  needs,  waivers,  when  feasible,  will 
be  considered  as  part  of  the  project’s  trade-off  analysis. 

Requirements  analysis  will  followr  an  iterative  process  that  addresses  identification  of  the 
need,  analysis  of  feasibility,  definition  of  system  operational  requirements.  [  (Blanchard  & 
Fabrycky,  2006)p.35].  To  track  the  performance  of  this  project,  measures  of  effectiveness  to 
govern  the  trade-off  analysis  will  be  defined  in  terms  of  technical  performance  measures  (TPM). 
One  example  of  a  potential  project  TPM  may  be  theoretical  time  to  field  a  new  capability. 
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Figure  6  (After  (Blanchard  &  Fabry  cky,  2006),p,58),  shows  the  tailored  approach  for  this 
project. 


Figure  6.  Major  Steps  in  the  Systems  Requirements  Definition  Process  (Alter  Blanchard 
and  Fabrycky  20116,  p.58) 

The  basic  and  derived  requirements  from  this  analysis  will  be  tracked  through  the  use  of 
tiered  requirements  traceability  matrices.  It  may  not  be  feasible  to  address  all  of  the  requirements 
during  the  Capstone  effort,  and  some  requirements  may,  by  necessity,  need  to  be  left  for  later 
updates.  Any  unaddressed  requirements  will  be  tracked  as  such  in  the  matrices. 

3,1,3  Functional  Analysis 

The  purpose  of  the  Functional  Analysis  is  to  identity  “what”  needs  to  be  done  to  satisfy 
the  stated  requirements.  The  top-level  requirements  provided  by  the  Stakeholders  will  be 
translated  into  top-level  functions,  fhese  functions  will  form  the  key  components  of  the 
integration  plan  being  developed.  Analysis  of  these  functions  shall  be  performed  to  ensure  that 
the  derived  requirements  are  allocated  to  the  appropriate  functions  and  satisfactorily  met. 

3,  t  ,4  AitIii  tectu  ral  Ail  al  ysis 

The  purpose  of  Architectural  Analysis  is  to  define  the  integration  process  approach.  The 
Architectural  Analysis  will  follow  an  “as-is”  /  “to-be”  approach.  The  current  architecture  will  be 
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captured  first,  and  from  which  the  4ito-be”  architecture  will  be  further  defined.  The  current 
architecture  representation  will  be  based  on  a  decomposition  of  the  functions*  and  then  project 
deliverables  (certifi cations  and  re-certifications  demands),  involved  in  the  current  system 
employed  to  integrate  a  payload  onto  a  STUAS.  The  iLto-be”  functional  architecture  will  be 
constructed  based  on  the  decomposition  of  lire  critical  functions  needed  in  the  system,  as  derived 
from  the  problem  statement,  problem  scope,  and  Stakeholder  input.  The  physical  architecture  of 
the  process  for  integration  of  capabilities  onto  a  system  will  be  the  allocation  of  the  critical 
functions  lo  the  project  deliverables  (documents,  forms,  databases,  or  templates)  needed  to 
achieve  PMA-263?s  rapid  integration  and  fielding  schedule  requirements. 

Tlic  system  architecture  will  provide  the  RAIN  team's  view  of  how  to  implement  rapid 
integration  and  fielding  of  a  new  capability  into  the  inventory  of  modular  STUAS.  In  order  to 
ensure  the  smoothest  possible  process  and  for  requirements  traceability,  all  technical 
requirements  will  be  documented  using  Vitech  CORE®. 

3.1.5  Modeling  and  Simulation  Process 

“All  models  are  bad,  but  sonic  arc  useful”  [  (George  E.P.  Box,  1987)p.424].  Because  of 
the  complicated  interactions  between  the  sub-processes  involved  in  integrating  a  payload  onto  a 
STUAS  and  approving  the  use  of  the  new  system,  M&S  will  he  used  to  represent  the  integration 
process.  It  will  be  used  as  a  tool  to  assist  in  understanding  the  current  process  and  various 
proposed  processes.  Simulation  will  be  used  lo  verify  the  model  of  the  current  process  and  to 
project  the  performance  oi'lhe  desired  and  planned  process  implementations.  The  desired 
process  is  the  one  that  addresses  all  potentially  required  certili cations  or  accreditations  in  the 
manner  that  minimizes  process  duration  without  resorting  to  waivers.  To  facilitate  this  analysis, 
flow  diagrams  will  be  used  to  optimize  the  integration,  certification,  and  testing  process. 
Intermediate  state  process  implementations  will  be  explored  lo  understand  l he  relalionship 
belween  schedule  compression,  cost,  and  risk  expansion  associated  with  different  combinations 
of  waivers  and  certifications.  The  outputs  of  these  simulations  will  be  used  to  identify  the 
efficient  frontier  of  risk  vs.  duration  associated  with  the  use  of  waivers,  and  rank  the  various 
options. 

The  model  will  be  built  of  simplifi cations  of  the  current  sub-processes  used  for  integrating  a 
payload  into  a  STUAS.  The  requirements  for  whether  or  not  to  perform  each  certification  (sub 
process)  in  the  current  process  are  not  well  understood  and  are  often  addressed  in  a  reactive 
fashion,  sometimes  when  identified  as  the  entry  criteria  for  a  different  certification  or  approval. 
The  often  reactive  start  of  each  certification  causes  statistical  special  cause  variation  in  the 
duration  oi'lhe  current  Ad  Hoc  process  (delays),  so  the  duration  distributions  are  believed  to  be 
non-normal.  Duration  distributions  for  each  sub-process  will  be  modeled  as  triangular 
(Raymond,  1999)  and  will  he  based  on  SME  predictions  for  best  case,  most  likely,  worst  case, 
and  where  available  historical  data.  Simulation  with  the  model  of  the  current  process  will  be 
used  to  verify  that  the  model  and  its  component  pails  are  appropriately  accurate  by  comparing 
the  simulation  output  to  expert  opinion  or  if  available  historical  data  on  past  payload 
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integrations1  mean  duration  and  duration  variation.  In  the  cases  where  the  distributions  are  not 
normal  measures  of  central  tendency  and  variation  other  than  the  mean  and  standard  deviation 
would  have  to  be  used  to  compare  expert  opinion  or  historical  data  to  the  simulation  results  at  the 
system  and  task  (certification)  levels.  Following  Dam's  recommendation  [  (Dam,  2006)  p.  14], 

Ihe  resultant  understanding  of  the  current  process  will  be  used  to  formulate  the  ultimately  desired 
i4to-bc”  process,  balancing  schedule,  cost,  and  systems  engineering  proficiency,  before  any 
intermediate  concepts  are  considered. 

[fie  desired  “to-be'1  process  will  be  modeled  using  the  building  blocks  that  were  verified 
in  the  model  of  the  current  process.  Ihe  desired  state  is  assumed  to  be  meeting  all  certification 
requirements  in  the  shortest  possible  time  without  resorting  to  waivers,  the  least  desired  stale  is 
assumed  to  be  waiving  all  certification  requirements*  Combinations  of  waivers  and  certifications 
are  assumed  to  be  intermediate  states  with  schedules,  costs,  and  performance  risks  scaled 
between  the  assumed  extremes.  Simulation  will  then  be  run  to  predict  its  performance. 

Because  it  is  often  impractical  to  implement  the  desired  process,  due  to  expense  or  schedule  or 
policy  impediments,  intermediate  processes  will  be  explored,  modeled,  and  simulated.  The 
results  will  be  used  to  pick  processes,  based  on  risk  and  integration  constraints,  to  implement  that 
are  better  than  the  current  one,  but  may  not  have  all  the  features  of  the  desired  “to-be 1  state. 

Simplified  representations  of  the  $ub*proce$$es  will  be  done  in  iGrafx®  and  Microsoft 
Excel®,  as  deemed  appropriate.  Simulations  of  the  process  and  sub-processes  will  be  run  in 
iGrafx  or  Risk  Simulator®.  The  applications  Minilab®  or  Microsoft  Excel®  will  be  used  lo 
quickly  provide  the  needed  descriptive  and  inferential  statistics  on  the  various  process  designs. 
Deliverables  will  include  static  views  of  the  models  and  statistical  analyses  of  the  results  of 
model  simulations  run  in  iGrafx  and  Risk  Simulator,  as  needed,  to  aid  in  communication  or 
provide  decision -quality  data  about  expected  performance  a  process  design. 

3.1.6  Cost  Estimation  Process 

This  section  is  to  estimate  the  cost  of  integrating  and  lidding  process  of  modular 
payloads  into  a  STUAS  and  will  involve  collecting  and  analyzing  data  based  on  scope  definition 
of  the  project.  Quantitative  models,  techniques,  and/or  tools  will  be  applied  to  predict  Non- 
Recurring  Engineering  cost  (low/med/high)  for  Ihe  whole  process  of  integration  and  fielding  and 
identify  all  variables  necessary  for  trade-off  analysis  between  risk,  cost,  and  schedule.  The 
process  will  be  separated  into  three  main  parts  to  ensure  the  accuracy  and  completeness  of  the 
whole  estimating  practice.  This  is  shown  in  Figure  7  below  and  highlighted  as  follows. 

Part  1  oft  lie  RAIN  Cost  Estimation  process  is  called  Project  Definition.  During  this  part, 
the  estimator  clarifies  the  reason  for  the  estimation  and  begins  to  understand  Ihe  project  that  will 
be  estimated.  As  the  estimate  is  being  conducted,  all  necessary  cost  elements  will  be  identified 
based  on  the  inputs  of  the  stakeholders,  including  all  the  possible  items  of  cost  contained  in  the 
cost  model.  Each  element  will  be  defined  so  that  all  costs  are  essentially  covered,  with  no 
duplications  within  the  stmeture.  lliese  elements  help  form  the  foundation  for  the  estimate  and 
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may  be  revisited  whenever  new  information  is  obtained  as  the  estimator  continues  throughout  the 
process. 

Part  2  of  the  RAIN  cost  estimating  process  mainly  focuses  on  selecting  and  administering 
the  cost  methodology,  which  will  guide  the  development  of  the  estimate  based  on  all  identified 
cost-related  assumptions  and/or  constraints.  As  methodologies  arc  selected  and  data  is  gathered, 
cost  estimating  templates  will  be  developed  and  even  the  cost  model  may  be  constructed  and 
refined  as  appropriate. 

Part  3  of  the  RAIN  cost  estimating  process  is  called  Estimate,  it  includes  the  actual 
conduct,  analysis,  presentation,  and  maintenance  of  the  cost  estimate.  .All  of  these  tasks  are 
important  in  their  own  right  and  together,  they  become  critical  for  a  defensible  and  complete 
estimate. 


Project 

Definition 


Figure  7:  Cost  Estimation  Process 


4  Risk  Management  Process 

The  RAIN  Team  will  have  a  risk  manager  who  is  responsible  for  tracking  all  the  risks 
associated  with  this  project,  both  technical  and  to  the  Capstone  Completion.  With  regard  to 
Capstone  completion,  the  manager  ensures  each  risk  lias  a  mitigation  plan,  and  the  mitigation 
plans  are  being  followed.  He  will  work  with  Ihc  team  leads  closely  on  the  Capstone  Completion 
risks  and  gather  team  inputs  to  feed  into  the  technical  risks. 

4.1  Risk  Identification 

It  is  the  responsibility  of  every  team  member  to  stay  vigilant  for  any  risks  that  may 
surface  within  any  of  these  areas,  requirements,  technical  baseline,  management,  schedule,  and 
external  factors  to  keep  this  Capstone  Project  on  schedule  and  to  meet  its  objectives. 

The  following  is  a  list  of  the  risks  that  have  been  identified  for  the  RAIN  Team  Capstone 

Project: 


A.  I  xis  s  of  tea  m  m em  ber(s) 

B.  Federal  budget  sequestration 

C .  Stak  ehol  d  ers  s  ee  n o  vat u  e 

D.  Lack  of  expertise  among  members 

E.  Lack  of  concurrence  from  a  Key  Group 

F.  Project  cannot  meet  schedule 
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G.  Imbalance  of  effort 

H.  Team  member  gets  sick 

I.  Accessibility  of  tools 

42  Risk  Analysis 

Hie  same  basic  process  will  apply  to  both  technical  risks  and  risks  to  completing  this 
Capstone  Project.  Each  risk  will  be  evaluated  independently  for  its  effect  on  the  applicable 
areas,  The  evaluation  will  look  sit  the  likelihood  and  the  consequence  of  each  risk  and  assign  it  a 
level  based  on  the  criteria  shown  in  the  following  tables  within  Figure  8.  Alter  Ihc  risk  lias  been 
assigned  a  level  for  each  of  the  two  areas  (performance  and  schedule)*  a  risk  will  be  categorized 
as  High.  Medium,  or  Low*  based  on  (lie  matrix  al  Ihe  lop  right  corner  of  Figure  8  for  each, 
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Figure  8,  Risk  Matrix  for  Payload  Integral  ion  Process 

When  evaluating  risks,  it  was  determined  that  by  working  fin-  in  advance  of  the 
Capstone’s  due  dales,  we  can  allow  for  additional  time  to  make  corrections  if  need  be.  For  this 
reason,  we  are  putting  more  emphasis  on  schedule  than  on  performance.  In  determining  a 
cumulative  Consequence  Factor  (CF)  for  each  risk,  a  weight  of  60%  and  40%  respectively  was 
given  to  ihe  Schedule  Impact  Factor  (SIF)and  Performance  Impact  Factor  (PIF)  respectively  as 
shown  in  Equation  L 


Page  22  of  34 


i  r  \j 


CF  =  0.6  S1F  +  0.4  PIF 


(1) 


The  final  value  of  the  consequence  was  then  rounded  to  its  nearest  integer. 

4.3  Risk  Mitigation 

For  each  risk  identified  in  Section  4.1,  a  mitigation  strategy  has  been  identified  for  each 
to  reduce  the  overall  risk  to  the  project.  As  a  result  there  is  no  high  risk  items  left  for  completion 
of  the  project.  All  moderate  risks  will  need  to  be  monitored  to  ensure  that  the  planned  mitigation 
strategies  are  executed  if  need  be  and  adjust  the  mitigation  strategies  for  each  accordingly. 

4.4  Risk  Tracking 

After  identifying  a  mitigation  strategy  for  each  of  the  high  and  moderate  risks,  the  final 
risks  level  was  obtained.  Figure  9  shows  each  of  the  risks  for  the  RAIN  Project  on  a  risk  matrix. 
Table  3  ftirther  shows  in  detail  each  of  the  risks  with  their  individual  values  for  SIF  and  PIF,  as 
well  as  a  detail  description  of  the  risk  and  a  mitigation  strategy  in  the  “Narrative”  column.  This 
figure  and  table  will  be  tracked  throughout  the  duration  of  the  project  to  ensure  consistent  risk 
implementation  should  any  of  these  risks  or  any  other  similar  to  these  occur. 


Risk  I.CVCI 


Motle  rale 


Ixm 


Figure  9  -  Risk  Matrix  for  RAIN  Project 
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Table  3:  List  of  Risks 


Rhk 

ID 

Rivk  Title 

Likelihood 

Overall 

Cinsrqucnce 

Sdipdile  Performance 

Narrative 

Risk 

Level 

A 

Loss  ofTeam 
Members) 

1 

4 

3 

5 

Los  tig  one  or  rrcre  members,  while  not  likely,  will  increase  the  workload  on  the  tenuring  numbers  and 
potentially  ewer  stress  the  remaning  team  merit  ers  It  might  abo  require  de-scoping  one  or  more  areas  to 
accommodate  workload  If  the  people  who  prepare  this  plan  leave,  the  other  merit  es  may  lack  some  of  the 
knowledge  of  a  particular  problem  Communication  can  reduce  some  of  this  burden 

Low 

B 

Federal  Budget 
Sequestration 

3 

3 

3 

3 

Profess  ors/SUkeholdenVSMEs  may  not  be  available  for  consolation  to  push  our  project  forward  There 
doesn't  seem  to  be  a  resolution  ccrnung  any  time  soon,  so  the  team  can  centime  performng  but  without 
stakeholder's  feedback  As  a  resul,  we  could  have  lots  of  corrections  to  make  later  m  the  project  which 
could've  been  taken  care  of  earlier  Sequestration  nuy  abo  lnrol  the  abihty  fee  our  team  to  meet  on  base 
facilities  and  use  of  communication  took 

Moderate 

C 

Stakeholders 

Sec  No  Value 

1 

5 

5 

5 

If  the  stakeholders  feel  this  project  adds  no  value  and  lose  riterest,  it  could  require  the  teamto  re-scope  the 
project  While  unlikely,  this  would  abo  put  us  significantly  behnd  The  consequence  gets  aggravated  if  it 
happens  later  in  the  project 

Moderate 

D 

Lack  of 

Bpertute 

Anting 

Merit  ers 

3 

2 

2 

2 

Not  enough  team  rrwrrfc  ers  hav  e  adequate  eapenence  *i  this  type  of  field  to  obtain  worthwhile  information 

Abo,  some  of  the  effort  relies  on  n  depth  knowledge  of  STUAS  and  access  to  said  mfcmraticn  above  what 
teammenbers  now  have  Lade  of  knowledge  can  be  easily  addressed  by  dong  addlwnal  research  orrelying 
on  our  resources  in  PMA  263 

Low 

E 

Luck  of 
Concurrence 
from  a  Key 

2 

4 

3 

5 

If  a  particular  groups  fe«k  that  the  project  c  not  meeting  ther  needs  orespectaticns.  it  can  potentially  delay  the 
project  untilther  concerns  are  addressed  While  this  would  be  disastrous  to  no  get  concurrence  from  a  key 
group  of  stakeholders,  keeping  everyone  informed  ofthngs  reduces  the  possibtfaty  ofhavng  anything  that 
would  set  back  the  proiect  signjfic*nlly 

Moderate 

F 

Project  (inn  oi 
Meet  Schedule 

3 

4 

5 

3 

If  for  any  reason,  including  but  not  limited  to  the  ones  stated  in  this  document,  the  project  cannot  rratntan 

schedule,  it  wou  Id  serious  ly  degrade  the  performance  of  the  team  and  delay  the  comp  letioo  of  the  overall 
project  Whikirray  vary  m  consequence,  worse  case  scenario  would  roqumde-scopaignordwtobeableto 
meet  dchv  ay  dale  of  Capstone  protect 

Moderate 

O 

Intalanoe  of 
Effort 

1 

3 

3 

4 

If  one  team  member  does  not  pull  his  weight,  it  willbrrg  down  the  entre  tearrts  performance  This  s  bemg 
addressed  by  havxig  backup  robs  in  each  section  of  the  project 

Low 

H 

TearnMenter 

Gets  Sick 

3 

2 

2 

3 

If  a  team  member  gets  sick  for  a  period  of  tme  t  would  cause  additional  stress  cm  other  members  which  are 
listed  as  backups  for  ther  role,  or  his  debvery  may  be  delayed  Working  ahead  of  schedule  allows  foe  extra 
slack  tane 

Low 

I 

Accessibility 

ofToob 

1 

2 

2 

3 

If  one  of  the  took  a  group  trasib  vr  &  using  to  woik  ther  particular  sections  (ic  CORE,  ErtcndSn*  Internet 

access,  etc )  is  tenporanly  cut  off,  the  teammay  delay  its  delwery 

Low 

5  Configuration/Change  Management  Process 

The  deliverables  created  by  the  RAIN  Team  will  be  in  the  form  of  documents, 
presentations,  architectures,  models,  and  analyses.  The  CM  Lead  will  maintain  a  copy  of  all 
deliverables  and  revisions  in  a  chronological  master  archive.  The  RAIN  Team  will  revise  each  of 
the  deliverables  as  necessary  prior  to  final  submittal.  The  RAIN  Team  internal  edits  will  be 
tracked  using  a  system  of  Numeric  Date  Time  revisions  (e.g.,  PMP  Rev  1  Febl  1600,  PMP 
Rev  2_Feb2_l 100,  significant  change  PMP  Rev  3_Feb  3  1 300,  and  on  out)  by  the  Lead  Editor. 

Once  a  deliverable  is  ready  for  submittal  it  will  be  published  with  an  alphabetical  ending 
(e.g.  PMP  Rev  A.  PMP  Rev  B,  etc).  If  a  deliverable  comes  back  to  the  Team  for  revision,  it  will 
pick  up  the  document  at  the  last  internal  numeric  designation  and  noted. 


6  I  PR’s  and  Deliverables/Schedulc 

The  RAIN  Team  Deliverables  are  outlined  in  Table  5  below  and  the  detailed  schedule  is 
shown  in  Appendix  C. 

6.1  I PRs  and  Deliverables 

Table  5  below  lists  each  major  IPR  and  milestone  associated  with  the  RAIN  Team  project 
for  the  SI0810  Capstone  Class. PM A-263  advisors  and  the  RAIN  Team  must  agree  that  the 
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required  deliverable(s)  are  completed  satisfactorily  before  an  IPR  or  Final  Report  is  considered 
complete. 


Table  5.  IPR  and  Deliverables  Schedule 


Milestone 

Description 

Deliverable 

Presentation 

Weekly  Group  Status  to  Advisors 

PowerPoint  Presentation 

Report/Update 

Assessment  of  Team  Members/Individual 

Assesments 

Report  Sheet 

Project  Plan  Outline 

Project  Plan  Outline/Rough  Draft  of  PMP. 
Problem  Definition  Refinement 

PowerPoint  Presentation 

Drafl  PMP 

Draft  of  PMP  to  Advisors  for  Review 

Draft  Project  Management  Plan 

PMP 

PMP  approval-reviewed  by  AA,  for  SE 
Ftept  Chair  Approval 

Project  Management  Plan 

IPR  #1  Brief 

Interim  Project  Review  -  Problem 
Background  Project  Management  Plan 

PowerPoint  Presentation 

IPR#2  Brief 

Interim  Project  Review-Project  Status 

PowerPoint  Presentation 

Draft  Final  Report 

Draft  Final  Report  for  Advisor  Review 

Draft  Final  Report  (Electronic) 

Final  Report 

Final  Report  for  submittal  to  Thesis 
Processing  Committee 

Final  Report  (Electronic) 

Final  Biief 

Brief  of  Project  to  Advisors  & 
Stakeholders  during  working  hours  @  Pax 
River  to  PMA-263 

Powerpoint  Presentation 

6.2  Schedule 

The  schedule  for  the  RAIN  Team  will  be  constructed  and  managed  using  Microsoft 
Project®.  The  schedule  includes  the  major  milestones  as  outlined  in  Figure  10.  The  detailed 
schedules  for  the  RAIN  Team  is  provided  in  Appendix  C.  Project  efforts  will  be  aligned  to  the 
schedule  in  regards  to  resource  planning  and  provide  a  visual  metric  for  Team  time  management. 
The  Microsoft  Project®  schedule  will  provide  the  detailed  plan  of  action  and  milestones  for 
project  execution. 
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SMALL  TACTICAL  UNMANNED  AIRCRAFT  SYSTEM  RAPID  PAYLOAD  INTGRATION  &  FIELDING  PROCESS 


IMPS  Quarter 


Requirements 
Milestones 

Systems  Engineering 
Initial  Research 

Conduct  Mssbn  Analysis  Dave  bp  Scenarios  & 
COfiOPS  Determine  Customers  ft.  Stakeholders 

Problem  Formulation 

Conduct  Stakeholders  Analysts  Define  &  Refine 
Rottein  Statement!  &  Scope  FferTorm  Funcltonat 
Analysis  Develop  Functional  A rchfleclure 

Analysis  of  Alternatives 

Develop  Alternative  Physical  Architectures 
ftrfwm  Modeling  &  Simulation  Assessing 
fterfer nance  of  these  Physical  Architectures 

Implementation 

Conduct  &  Complete  Systems  Analysis 
Conduct  Decision  Anstysis 
Ra command  Perf  erred  Alternative 
Rovlde  Addllonal  hs  Ighrls 


Winter  2013 


Spring  2013 


Summer  2013 


T 

T 


Deliverables 


” 


IPR«2A  FINAL  Mfinal 

T  WBF 


*♦ 

TT 


REPORT  TT0RIEF 

?  I 


Qmitiilies| 


Figure  10:  Schedule  Ov  erview  of  Major  Milestones 
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Appendix  A  Team  Bios 

Luis  A.  Conde: 

Mr.  Luis  Conde  graduated  from  Virginia  Tech  in  2009  with  a  degree  in  Mechanical 
Engineering.  With  his  background  in  thermo-fluid  research  and  propulsion,  he  was  hired  by 
NAVAIR  to  work  in  the  Propulsion  and  Power  Department,  where  he  has  worked  for  the  past 
four  years.  He  started  out  by  supporting  the  turbine  design  group  for  the  first  year,  working  on 
the  F404  and  1*56  engines.  After  that  he  moved  on  to  become  a  project  engineer  for  the  F/A-l  8 
and  EA-18G  Auxiliary  Power  Systems,  where  he  has  worked  at  ever  since.  lie  is  responsible  for 
the  design  and  integration  of  the  various  component  s,  the  safety  and  mitigation  planning,  and  the 
lead  on  any  improvement  projects  of  the  same.  Luis  is  currently  attending  the  Naval  Post¬ 
graduate  School  pursuing  a  master's  degree  in  Systems  Engineering. 

Christopher  Iron  hill: 

Mr.  Ironhill  has  1 8  years  of  process  design  experience  in  both  private  sector 
manufacturing  and  defense  test  and  evaluation  support  infrastructure.  lie  worked  as  a 
manufacturing  engineer  who  designed  new  processes;  designed  and  built  tooling  and  fixtures; 
designed,  fabricated,  and  programmed  automated  assembly  equipment.  His  work  supported  the 
building  of  automotive  alternators  and  starters  as  well  as  medical  equipment  lead  wires  and  cable 
assemblies.  For  six  years,  he  worked  as  a  telecommunications  systems  engineer  designing  and 
implementing  fiber  optic  and  microwave  links  used  to  transport  data  and  control  signals  between 
range  instrumentation  equipment,  operations  control,  and  data  processing  on  the  NAWCWD  test 
and  evaluation  ranges.  During  his  time  in  Range  Communications,  he  implemented  process 
improvements  for  the  Ranges  Department  at  Point  Mugu.  He  is  a  graduate  of  the  Naval 
Leadership  Development  Program  (NLDP)  where  he  received  both  leadership  training  and  Lean 
Six  Sigma  Black  Belt  certification.  Additionally,  he  has  earned  American  Society  of  Quality 
certification  as  a  Department  of  the  Navy  Lean  Six  Sigma  Black  Belt.  He  also  has  DAWIA  level 
III  certification  in  SE  and  Test  &  Evaluation.  Currently  he  is  assigned  to  the  NAVAIR  Airborne 
Instrumentation  Systems  Division  (AISD)  as  a  Project  Manager  where  he  leads  the  development, 
design,  qualification,  and  manufacturing  of  telemeters  used  on  AIM-9X  and  HARM  test 
missiles.  He  has  a  Bachelor  of  Science  from  the  University  of  California  at  Santa  Barbara  in 
Mechanical  Engineering  and  is  completing  his  Master  of  Science  in  SE  from  the  US  Naval 
Postgraduate  School. 

Frederick  A.  Lancaster: 

Mr.  Lancaster  has  over  20  years  of  corrosion  control  and  metal  finishing  experience  with 
department  of  defense  products  ranging  from  ammunition,  ships,  land  systems  and  vehicles  to 
aircraft.  His  work  has  encompassed  industrial  production,  research  and  development,  equipment 
design  and  field  implementation  of  corrosion  control -related  products  for  aircraft  and  other  DOD 
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systems.  He  is  currently  assigned  to  the  NAVAIR  Corrosion  and  Wear  Branch  of  the  Materials 
Engineering  Division  Headquarters  NAVAIR  Patuxent  River,  MD  as  Lead  Corrosion  Engineer 
where  he  develops  and  leads  science  and  technology  pro  jects  related  to  the  mitigation  of  material 
degradation  on  Naval  Aviation  assets.  He  is  also  the  head  Corrosion  Acquisition  Engineer  on  the 
CH53K  Heavy  Lift  Helicopter  program  for  PMA-261.  He  has  a  BS  degree  in  Physics  from 
Frostburg  State  University  and  is  completing  his  Masters  in  SE  from  the  US  Naval  Postgraduate 
School. 

Diane  T.  1a: 

lor  almost  7  years  of  being  employed  at  NAVAIR,  Mrs.  Ly  has  been  continuously 
working  as  an  assembly  language  developer  at  SWDTT  (Software  Development  Task  Team). 

She  constantly  provides  support  AN/AYK-14  Mission  Computer  software  development  by 
providing  complete  life-cycle  support  for  the  F/A-18  mission  computer  operational  flight 
programs  in  the  areas  of  Joint  Helmet  Mounted  Cueing  System  (JHMCS),  Expanded  Multi- 
Source  Integration  (EMSI),  Gross  Weight  and  Software  Configuration,  Complimentary 
Navigation  Message  (CNM),  Maintenance  Status  Panel  (MSP)  Code,  Up  Front  Control  Display 
(UFCD),  and  some  other  software  related  SORs.  Mostly,  she  performs  software  engineering 
tasks  covering  the  entire  software  life-cycle  from  requirements  analysis,  design,  and  coding  to 
unit  and  system  integration  testing.  Besides,  she  also  includes  assisting  in  the  engineering  efforts 
to  analyze  fleet  anomaly  reports,  determine  solutions  to  the  stated  problems,  and  design  and 
implement  corrections  to  the  specific  OFP.  Regarding  educational  background,  she  graduates 
from  a  BS  Degree  in  Computer  Science  at  Cal  Poly  Pomona  University  and  is  currently  w  orking 
on  her  Masters  in  Engineering  Systems  from  the  US  Naval  Postgraduate  School. 

Bryan  R.  Otis: 

Mr.  Bryan  Otis  attended  college  at  Old  Dominion  University,  and  received  a  BS  in 
Mechanical  Engineering,  with  a  concentration  in  Aerospace  Engineering.  He  did  his  internships 
as  in  electrical  engineering  and  applied  physics’  research,  before  he  joined  NAVAIR  as  a 
Sensors  and  Imagery  Engineer.  Currently  he  works  as  the  NAVAIR  4.5. 1.4  Avionics  Systems 
Project  Engineer  assigned  to  the  Navy/Marine  Corps  Small  Tactical  Unmanned  Air  Systems 
(STUAS)  Program  office,  PMA-263.  Primary  responsibilities  include  providing  avionics  SE 
oversight,  and  w  orking  as  a  Team  lead  to  Subject  Matter  Experts  (SMEs).  Responsible  for  all 
Avionics  across  multiple  UAS  platform  including  RQ-21A(STUAS),  Scan  Eaglc/Curscr, 
Aerosonde  4.7  G,  RQ-7  (Shadow),  RQ-1 1 B  (Raven),  T-Hawk,  Wasp  III,  Wasp  IV,  Puma.  Other 
duties  include  special  projects  in  support  of  long  term  UAS  improvement  projects,  and  urgent 
needs  in  support  of  past  and  present  combat  operations  in  Operation  Iraqi  Freedom  (OIF),  the 
Global  War  on  Terror  (GWT),  and  Operation  Enduring  Freedom  (OEF). 

Angel  M.  Perez: 
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Ms.  Angel  Perez  received  her  undergraduate  degree  in  Materials  Engineering  from  the 
University  of  California  -  Los  Angeles,  as  well  as  a  commission  into  the  United  States  Navy  as  a 
Nuclear  Power  Officer,  f  ollowing  her  stint  as  an  active  duty  Naval  Officer,  she  taught  Reactor 
Theory  at  Pearl  Harbor  Naval  Shipyard  to  engineers  conducting  repairs  modifications  on  US 
Navy  submarines.  She  transitioned  to  a  SE  career  with  Defense  Contract  Management  Agency 
(DCMA)  at  Raytheon  Tucson  on  the  Enhanced  Sea  Spairovv  Missile  (ESSM)  program, 
followed  by  the  Standard  Missile  Six  (SM-6)  program  with  Naval  Surface  Warfare  Center 
(NSWC)-Port  Hueneme  Division.  Upon  relocating  to  the  East  Coast,  she  became  a  Systems 
Engineer  for  AgustaWestlandBell,  performing  Requirements  Management  for  the  Presidential 
Helicopter  Program.  She  returned  to  federal  government  service  as  the  Deputy  Class  Desk  for 
the  Unmanned  Combat  Air  Systems  -  Demonstration  (UCAS-D).  She  is  currently  the  Class 
Desk.  Systems  Engineer  for  PMA-263  Group  1  UAS  at  NAS  Patuxent  River,  MD  providing 
technical  expertise  for  small  UAS*  that  weigh  less  than  55  lbs. 

Nam  T.  Tran: 

Mr.  Tran  has  been  working  with  NAY  AIR  4.1.4  Software  Engineering  Branch  at  China 
I,ake  for  over  4-1/2  years  crossing  multiple  programs.  He  has  experiences  with  database  design 
using  PL/SQL  programming  interface  with  java  application  for  web  design  at  Intelligent 
Division.  He  is  also  knowledgeable  with  MIL-STD-1 553  data  bus  and  telemetry  communication 
for  real  time  flight  test  and  post  data  analysis  supporting  RAAF  Supper  Hornet,  TACT  AIR  EW, 
EW  community,  and  FMS  programs.  On  top  of  that,  he  is  also  an  expert  of  using  C++  to  develop 
Graphical  User  Interface  (GUI)  for  MIL-STD-1 5 53  Server,  decoder,  and  data  analysis  test  tools. 
While  working  with  Software  Engineering  group  at  China  Lake,  he  has  applied  Personal 
Software  Process  (PSP)  and  Team  Software  Process  (  fSP)  to  complete  the  projects.  Beside 
software  engineering  related  fields,  he  also  has  more  than  2  year  experience  with  Structural 
Analysis  of  heavy  facility  structure  as  well  as  Road  and  Bridge  Design  in  Transportation.  He 
completed  few  big  projects  involving  in  Civil  Engineering  such  as  FWY  1 5  Interstate  widening, 
95%  drainage  design  of  FWY  215  State  of  California,  and  bridge  alignment  at  Junction  FWY 
215  and  FWY  60.  Educationally,  he  has  a  Bachelor  of  Science  Degree  from  Cal  Poly  Pomona  in 
Civil  Engineering  and  is  in  progress  of  achieving  his  Master  of  Science  Degree  in  SE  from  the 
US  Naval  Postgraduate  School. 
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Appendix  B  Mannnemrnt  and  Working  Groups 
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Appendix  E  Abbreviations  and  Acronyms 


APEO 

Assistant  Program  Executive  Office 

B&F 

Blanchard  &  Fabrecky 

CF 

Consequence  Factor 

CM 

Configuration  Management 

CMP 

Configuration  Management  Plan 

DCO 

Defense  Connect  Online 

DCMA 

Defense  Contract  Management  Agency 

DoD 

Department  of  Defense 

DoDAF 

Department  of  Defense  Architectural  Framework 

DoN 

Department  of  the  Navy 

ESSM 

Enhanced  Sea  Sparrow  Missile 

GWT 

Global  War  on  Terror 

IEEE 

Institute  of  Electronics  and  Electrical  Engineers 

IC'D 

Interface  Control  Document 

IPR 

Interim  Program  (or  Project)  Review 

IPT 

Integrated  Product  Team 

LSRB 

Laser  Safety  Review  Board 

M&S 

Modeling  &  Simulation 

MIL-STD 

Military  Standard 

NAVAIR 

Naval  Air  Systems  Command 

NAS 

Naval  Air  Station 

NOSSA 

Naval  Ordnance  Safety  &  Security  Activity 

NSWC 

Naval  Surface  Warfare  Center 

OEF 

Operation  Enduring  Freedom 

OSI) 

Office  of  the  Secretary  of  Defense 

PEO 

Program  Executive  Ollice 

PIF 

Performance  Impact  Factor 

PM 

Project  Manager 

PMA 

Program  Manager,  Air 

PMP 

Project  Management  Plan 

RAIN 

RApid  INtegration 

RMP 

Risk  Management  Plan 

SE 

Systems  Engineering 

SEP 

Systems  Engineering  Plan 

SIF 

Schedule  Impact  f  actor 

SM 

Standard  Missile 

SME 

Subject  Matter  Expert 

s  i  r  as 

Small  Tactical  Unmanned  Arial  System 

SWAP 

Size,  Weight,  and.  Power 

T&E 

Test  and  Evaluation 

TAE 

Technical  Authority  Expert 

TPM 

Technical  Performance  Measures 

TRL 

Technology  Readiness  Level 

UAS 

Unmanned  Aircraft  System 
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UCAS-D 

USN 

u&w 

v&v 

WSESRB 


Unmanned  Combat  Air  Systems-Demonstration 

United  States  Navy 

Unmanned  &  Weapons 

Verification  &  Validation 

Weapons  Systems  Explosive  Safety  Review  Board 
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APPENDIX  L.  SELECTED  PLATFORM  STUAS  BACKGROUND 


RQ-21A  (Integrator) 


Figure  41:  RQ-21  (Rector  2012) 


The  RQ-21  A  provides  persistent  maritime  and  land-based  tactical  Reconnaissance, 
Surveillance,  and  Target  Acquisition  (RSTA)  data  collection  and  dissemination 
capabilities  to  the  warfighters.  For  the  United  States  Marine  Corps  (USMC),  the  RQ-21 
seen  in  Figure  41  will  provide  the  Marine  Expeditionary  Force  (MEF)  and  subordinate 
commands  (divisions  and  regiments)  a  dedicated  Intelligence,  Surveillance,  and 
Reconnaissance  (ISR)  system  capable  of  delivering  intelligence  products  directly  to  the 
tactical  commander  in  real  time.  For  the  United  States  Navy  (USN),  the  RQ-21  will 
provide  persistent  RSTA  support  for  tactical  maneuver  decisions  and  unit-level  force 
defense/force  protection  for  Navy  ships,  Marine  Corps  land  forces,  Navy  Expeditionary 
Combat  Command  (NECC)  forces  and  Navy  Special  Warfare  (NSW)  units.  It  is 
envisioned  that  the  United  States  Air  Force  (USAF)  will  employ  the  Integrator  to  provide 
persistent  RSTA  in  support  of  security  forces,  integrated  base  defense  and  convoy 
protection  requirements,  and  meteorological  survey  and  data  analysis  by  weather 
personnel(Rector  2012). 

RQ-7B  (Shadow) 
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Figure  42 :  RQ-7B  (Shadow)  (From  263  UAS  Portfolio  Brief,  2012) 

The  RQ-7B  UAS  shown  in  Figure  42  provides  a  dedicated  RSTA,  Intelligence, 
Battle  Damage  Assessment  (BDA)  and  Force  Protection  capability  to  USMC  units.  The 
RQ-7B  shares  the  same  system  baseline  configuration  as  the  Army’s  STUAS  POR, 
commonly  referred  to  as  the  Shadow  UAS. 

RQ-7B  UAS  consists  of  four  (4)  air  vehicles  (each  configured  with  an  electro¬ 
optic  (EO)/inffared  (IR)  sensor  payload  with  laser  designator  (LD)  capability),  launcher, 
ground  control  station,  attrition  engine,  and  support  equipment  including:  power 
generation,  communications  equipment,  automated  recovery  equipment,  remote  video 
terminals,  vehicle  mounted  shelters,  and  High  Mobility  Multipurpose  Wheeled  Vehicles 
(HMMWV).  Each  system  is  equipped  with  one  Maintenance  Section  Multifunctional 
Vehicle  and  is  supported  by  a  Mobile  Maintenance  Facility  (Rector  2012). 

ScanEagle 
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The  ScanEagle  family  of  systems,  including  the  ScanEagle  shown  in  Figure  43, 
Night  Eagle,  and  CRUISER  UAS,  provides  ISR  capabilities  through  an  ISR  Services 
Contract.  This  Contract  is  an  interim  solution  to  Naval  Commanders’  maritime  and 
littoral  ISR  capability  gaps  and  pending  RQ-21A  Integrator  Initial  Operational  Capability 
(IOC).  ScanEagle  currently  provides  Overseas  Contingency  Operations  (OCO)  surge 
assets  with  an  organic,  tactical  level  ISR  asset  to  support  full  spectrum  operations  (Rector 
2012). 

Aerosonde  4.7  G 


k 
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Figure  44:  Aerosonde  4.7  G  (Rector  2012) 

The  Aerosonde  4.7  G  shown  in  Figure  44  provides  ISR  capabilities  through  an 
ISR  Services  Contract.  This  Contract  supports  USMC  units  in  support  of  Operation 
Enduring  Freedom  (OEF)  and  the  Global  War  on  Terror  (GWOT)  stationed  in 
Afghanistan.  It  is  an  interim  solution  to  ISR  capability  gaps  and  pending  RQ-21A 
Integrator  IOC. 

Arcturus 


Figure  45 :  Arcturus  (Rector  20 1 2) 

The  Arcturus  UAS  shown  in  Figure  45  was  designed  to  provide  an  ISR  capability 
through  an  ISR  Services  Contract.  This  contract  supports  military  units  in  support  of  OEF 
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and  GWOT.  It  is  an  interim  solution  to  ISR  capability  gaps  and  pending  RQ-21A 
Integrator  IOC. 

RQ-12A  (Wasp  IV) 


Figure  46:  WASP  IV  (Rector  20 1 2) 


The  USMC  Wasp  Micro  Unmanned  Aerial  Vehicle  (MUAV)  in  Figure  46 
provides  near  real-time  area  reconnaissance  required  by  the  platoon  and  rifle  squad.  The 
system  greatly  reduces  the  ISR  request-to-response  timeframe,  and  eliminates  delays  or 
denials  for  coverage  from  higher  headquarters  due  to  an  imbalance  of  UAS  assets  to 
requests.  The  system  provides  the  small  unit  with  still  images  and  live  video  out  to  line- 
of-sight  (LOS)  ranges  of  5  km.  Wasp  provides  an  operational  capability  in  the  following 
areas:  remote  reconnaissance  and  surveillance,  force  protection,  convoy  security,  target 
acquisition,  and  battle  damage  assessment  (Rector  2012). 

RQ-20A  (PUMA) 


Figure  47:  RQ-20  (Puma)  (Rector  2012) 

Figure  47  PUMA  delivers  flexibility,  endurance  and  a  payload  capability 
unmatched  by  other  systems  in  its  vehicle  class.  With  a  wingspan  of  9.2  feet,  this 
lightweight,  all-environment,  hand-launched  UAS  provides  aerial  observation  at  LOS 
ranges  up  to  20  kilometers.  The  system  is  deployed  with  the  USMC  and  USN  Special 
Forces.  The  systems  provide  Route  Clearance  Platoons  (RCP)  and  Combat  Logistics 
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Patrols  (CLP)  the  required  ISR  asset  that  allows  them  to  scan  an  area  prior  to  moving 
through  it  in  order  to  detect  Improvised  Explosive  Devices  (IEDs),  IED  materials  and 
IED  emplacement  teams  and  after  clearing  it  to  monitor  for  re-seeding. 

RQ-11B  (Raven) 


Figure  48:  RQ-1  IB  (Raven)  (Rector  2012) 

Raven  in  Figure  48  is  a  small,  reusable,  back-packable  UAS  used  for  “over-the- 
hill”  reconnaissance  at  the  company/detachment  level.  It  is  hand-launched  and  flies  under 
manual  operator  control  or  via  a  pre-programmed  route.  It  uses  onboard  sensors  and 
communications  equipment  to  gather  and  transmit  live  airborne  video  imagery,  compass 
headings,  and  location  information  back  to  the  ground  control  station  and  remove  video 
terminals  out  to  a  LOS  range  of  10  km.  The  Raven  enables  operators  to  navigate,  search 
for  targets,  recognize  terrain,  and  record  all  information  for  analysis. 
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